Автор Тема: Безопасно ли обновляться из Сизифа сейчас?  (Прочитано 3852 раз)

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
I. Предпосылки, почему данная тема вообще возникла:

1. Хекерные группировки объявили России кибервойну. В частности Anonymous устроила атаку вида "отказ в обслуживании" на сайт Russia Today. Якобы пророссийская группировка Conty угрожала противникам России, вскоре в Сеть "слили" их переговоры за год, с именами и фамилиями (очевидно, для придания достоверности).
2. Упомянутый в первом сообщении вандал с сердечками поудалял файлы пользователей его программы.
3. Крупнейший интернет-провайдер Ростелеком уведомил (см. вложение) пользователей, что обновлять операционную систему не стоит.
Перечисленные атаки направлены на устрашение пользователей, странное на первый взгляд заявление Ростелеком намекает, что ситуация не контролируется.

II. Почему я перевёл данную тему в обсуждение успешно внедрённого в другую ОС переполнения стека? https://forum.altlinux.org/index.php?topic=45867.msg367613#msg367613

1. Справедливо было замечено https://forum.altlinux.org/index.php?topic=45867.msg367611#msg367611
что "Сделать дыру, которая будет дырой только для России, проблематично. Дыра она для всех."
2. Вышеупомянутая проблема решается целевой атакой на российский дистрибутив. Террорист хочет запугать людей, потому подойдёт один любой. Если при этом пострадают и зарубежные пользователи - террористу на руку, можно поднять шум, что это вина разработчиков.

3. Предполагаемый сценарий атаки:
а) преподаватель информатики Vasily Pupkin из села Карлук Иркутской губернии создаёт запись в системе учёта ошибок "у детей в школе не работает программа Х";
б) майнтайнер подтверждает ошибку, естественно, на исправление требуется время и задача сдвигается из-за приоритетов;
в) через день-два Vasily Pupkin пишет, что нашёл решение на форуме операционный системы У, прочитал вот тут Вики, собрал сам пакетик, у него всё работает, спасибо, до свидания;
г) майнтайнер никому ничего не должен, потому берёт патчик (он же работает!) и решает проблему;
д) задача атакующего - отложить эксплуатацию, что бы пройти QA - решается существенно проще, чем маскировка в коде проверки локали RU.

В данном сценарии, кстати, Сизиф выглядит заметно безопаснее стабильной версии, поскольку его пользователи априори готовы к проблемам, и ущерб кажется меньше.

А я должен?
Написать самое глупое сообщение - это 5 минут. Посмотреть патч и найти ошибку - это 5 минут. Выбор, как и выводы, каждый делает сам.
« Последнее редактирование: 23.03.2022 12:16:23 от trs »

Оффлайн andrew_b

  • Завсегдатай
  • *
  • Сообщений: 506
Посмотреть патч и найти ошибку - это 5 минут. Выбор, как и выводы, каждый делает сам.
Только вы эти выводы сами почему-то не делаете.
Как вам уже написали, вы несёте ахинею. Ваш патч совсем к другой ветке развития rpm. К Альту это не имеет никакого отношения.

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
Только вы эти выводы сами почему-то не делаете.
Свои выводы я уже приводил, повторяю для невнимательных: дистрибутив, куда было успешно внедрено вышеприведённое переполнение стека, непригоден к использованию, поскольку "майнтайнеры" не справляются со своей задачей (имеются и иные факторы, в частности, неоднократный взлом сайта).

Есть мнение, что в Альте ситуация существенно лучше, хотелось бы увидеть подтверждение, в том числе и вот этому:
В случае свободного софта исходники должен просматривать мантейнер пакета перед сборкой. И подобное выявлять.
По факту эксплуатации непосредственно в Альте обсуждать может быть уже поздно.
« Последнее редактирование: 25.03.2022 05:35:40 от trs »

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
Упростил патч, выкинул нерелевантный код. Теперь совсем как в букваре по программированию. На следующей неделе приведу исправление (надеюсь, вероятный противник не успеет отформатировать мне систему).
/**
 * Run a dependency set loop against rpmdb triggers.
 * @param psm package state machine data
 * @param tagno dependency set to run against rpmdb
 * @param arg2 scriptlet arg2
 * @return RPMRC_OK on success
 */
static rpmRC runScriptTriggersLoop(rpmpsm psm, rpmTag tagno, int arg2)
/*@globals rpmGlobalMacroContext, h_errno,
fileSystem, internalState @*/
/*@modifies psm, rpmGlobalMacroContext,
fileSystem, internalState @*/
{
    static int scareMem = 0;
    const rpmts ts = psm->ts;
    rpmfi fi = NULL;
    rpmds sourceDs = memset(alloca(sizeof(*sourceDs)), 0, sizeof(*sourceDs));
    char * depName = NULL;
    char * evr;
    char * ptr = NULL;
    ARGI_t instances = NULL;
    rpmmi mi;
    Header triggeredH;
    rpmRC rc = RPMRC_OK;
    int xx;
    rpmtsi pi;
    rpmte p = NULL;
    int n;

    if (tagno == RPMTAG_BASENAMES || tagno == RPMTAG_DIRNAMES)
n = (psm->goal == PSM_PKGINSTALL) ? ts->numAddedFiles : ts->numErasedFiles;
    else
n = ts->orderCount;

    evr = memset(alloca(n * 64 * sizeof(*evr)), 0, n * 64 * sizeof(*evr));
    ptr = evr;
    sourceDs->tagN = tagno;
    sourceDs->Type = tagName(tagno);
    sourceDs->Count = n;
    sourceDs->i = -1;
    sourceDs->N = memset(alloca(n * sizeof(*sourceDs->N)), 0, n * sizeof(*sourceDs->N));
    sourceDs->EVR = memset(alloca(n * sizeof(*sourceDs->EVR)), 0, n * sizeof(*sourceDs->EVR));
    sourceDs->Flags = (evrFlags *) memset(alloca(n * sizeof(*sourceDs->Flags)), 0, n * sizeof(*sourceDs->Flags));

    pi = rpmtsiInit(ts);
    while ((p = rpmtsiNext(pi, psm->goal == PSM_PKGINSTALL ? TR_ADDED : TR_REMOVED)) != NULL) {
if (p->isSource) continue;
if ((fi = rpmtsiFi(pi)) == NULL)
    continue;
if (tagno == RPMTAG_BASENAMES || tagno == RPMTAG_DIRNAMES) {
    fi = rpmfiInit(fi, 0);
    if (fi != NULL) {
while (rpmfiNext(fi) >= 0) {
    sourceDs->N[++sourceDs->i] = (tagno == RPMTAG_DIRNAMES ? rpmfiDN(fi) : rpmfiFN(fi));
}
    }
} else {
    char *ptr = evr;
    if (rpmteE(p)) ptr = stpcpy(stpcpy(ptr, rpmteE(p)), ":");
    ptr = stpcpy(stpcpy(stpcpy(ptr, rpmteV(p)), "-"), rpmteR(p));
    if (rpmteD(p)) ptr = stpcpy(stpcpy(ptr, ":"), rpmteD(p));
    sourceDs->N[++sourceDs->i] = rpmteN(p);
    sourceDs->EVR[sourceDs->i] = evr++;
    sourceDs->Flags[sourceDs->i] = RPMSENSE_EQUAL;
}
    }

    xx = rpmteClose(p, ts, 0);
    pi = rpmtsiFree(pi);

    if (sourceDs->i == -1)
return rc;

    /* Fire elements against rpmdb trigger strings. */
    for(sourceDs->i = 0; sourceDs->i < (int)sourceDs->Count; sourceDs->i++) {
const char * depName = sourceDs->N[sourceDs->i];
unsigned prev, instance;
unsigned nvals;
ARGint_t vals;


if (!depName || !*depName)
    return rc;

if (_psm_debug)
    rpmlog(RPMLOG_DEBUG, "--> %s:%d depName: %s tagno: %d ix: %d\n", __FUNCTION__, __LINE__, depName, tagno, sourceDs->i);

if (depName[0] == '/' && psm->Tmires != NULL) {
    miRE mire;
    int j;

    /* XXX mireApply doesn't tell which pattern matched. */
    for (j = 0, mire = psm->Tmires; j < psm->nTmires; j++, mire++) {
const char * pattern = psm->Tpats[j];
size_t npattern = strlen(pattern);
if (tagno == RPMTAG_DIRNAMES && !PATT_ISDIR(pattern, npattern))
    continue;
if (mireRegexec(mire, depName, 0) < 0)
    /*@innercontinue@*/ continue;

/* Reset the primary retrieval key to the pattern. */
depName = pattern;
/*@innerbreak@*/ break;
    }
}

/* Retrieve triggered header(s) by key. */
mi = rpmtsInitIterator(ts, RPMTAG_TRIGGERNAME, depName, 0);
nvals = argiCount(instances);
vals = argiData(instances);
if (nvals > 0)
    xx = rpmmiPrune(mi, (uint32_t *)vals, nvals, 1);

prev = 0;
while((triggeredH = rpmmiNext(mi)) != NULL) {
    instance = rpmmiInstance(mi);
    if (prev == instance)
/*@innercontinue@*/ continue;
    rc |= handleOneScriptTrigger(psm, sourceDs, triggeredH, arg2);
    prev = instance;
    xx = argiAdd(&instances, -1, instance);
    xx = argiSort(instances, NULL);
}
mi = rpmmiFree(mi);
    }

    instances = argiFree(instances);

    return rc;
}
Если к тому времени никто не укажет на ошибку в коде - очевидное переполнение стека - значит обсуждать вопросы безопасности на данном форуме не с кем (компетентные люди слишком редко сюда заглядывают, шибко заняты и т.п.). Аргументы "ахинея", "бред", "дебил" читать было бы очень весело, если бы было от кого.
« Последнее редактирование: 25.03.2022 05:56:25 от trs »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 7 766
(имеются и иные факторы, в частности, неоднократный взлом сайта).
О каком сайте речь?

Онлайн jobless

  • Давно тут
  • **
  • Сообщений: 300
    • Email
компетентные люди слишком редко сюда заглядывают
Они никогда сюда не заглядывали, вам это пытались дать понять несколько раз.
Вам сюда https://www.altlinux.org/Списки_рассылки
« Последнее редактирование: 25.03.2022 13:35:15 от jobless »
Рассвет наступит неизбежно!

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 7 766
компетентные люди слишком редко сюда заглядывают
Они никогда сюда не заглядывали, вам это пытались дать понять несколько раз.
Вам сюда https://www.altlinux.org/Списки_рассылки
На самом деле и это может не помочь, в devel@ ему не написать, а community@/sisyphus@/разное тоже не все читают. :-) А ещё там могут послать с такими наездами и, скорее всего, так и сделают. ;-)

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
компетентные люди слишком редко сюда заглядывают
Они никогда сюда не заглядывали, вам это пытались дать понять несколько раз.
Вам сюда https://www.altlinux.org/Списки_рассылки
Человек пришёл на форум и задал насущный вопрос. Сейчас идёт 4-я станица темы, какие-то представители интернет провайдеров из Самары рассуждают о высших материях.

Можно было сразу ответить, что здесь не место для подобных вопросов. Тогда бы не пришлось применять средства объективного контроля, что бы получить подтверждение в явном виде.

Лучше бы кому-то из руководства сделать заявление "мы предприняли все необходимые меры", что бы люди не беспокоились.


(имеются и иные факторы, в частности, неоднократный взлом сайта).
О каком сайте речь?
Возвращаем контекст, который упустил эксперт по "кто кому чего должен":

"дистрибутив, куда было успешно внедрено вышеприведённое переполнение стека, непригоден к использованию, поскольку "майнтайнеры" не справляются со своей задачей (имеются и иные факторы, в частности, неоднократный взлом сайта).

Переполнение стека - в rpm5, то есть не в Альте, в другом дистрибутиве. Про это радостно заявлял сам эксперт ("а каким боком rpm5 относится к ALT Linux?") https://forum.altlinux.org/index.php?topic=45867.msg367678#msg367678
Поскольку все ошибаются, одного переполнения мало для категоричных выводов. Потому в скобочках упомянуты другие признаки отсутствия компетенций. В частности ломали сайт той компании (повторяю, это не Альт!), как минимум дважды пользователи писали им про это во ВКонтакт.

А поскольку сайт и дистрибутив той компании - простите за такую подробность - фуфло, разумно использовать другой, то есть Альт.
Поскольку та компания бросает тень на отечественного производителя, хотелось бы найти подтверждение, что здесь лучше (ещё раз: я это знаю, но автор темы сомневается). Примером такого подтверждения мог бы служить ответ с указанием на ошибку в патче.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 7 766
Лучше бы кому-то из руководства сделать заявление "мы предприняли все необходимые меры", что бы люди не беспокоились.
Руководства чего? Сообщества? Вы на каком ресурсе находитесь? Вон, сверху написано. Эмблема тоже ни разу не Базальт СПО, или чья-то ещё.

Пишите производителям тех дистрибутивов, которые Вас интересуют. То, что сотрудники того же Базальт СПО бывают и здесь, не означает обязанности читать тут регулярно и на что-то отвечать.
Примером такого подтверждения мог бы служить ответ с указанием на ошибку в патче.
Экзаминатор нашёлся. Экзамены будете с учеников требовать, когда/если преподавать пойдёте.
« Последнее редактирование: 26.03.2022 14:23:50 от asy »

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
Итак, исписано 3 страницы, а очевидная ошибка в функции https://forum.altlinux.org/index.php?topic=45867.msg367779#msg367779
не обнаружена, поскольку компетентные люди сюда не заглядывают

На самом деле там сразу несколько ошибок, приводящих к переполнению стека.
Размер стека мы не знаем, потому всякая аллокация блока произвольного размера на стеке потенциально приводит к ошибке.
Вот так писать нельзя:
evr = memset(alloca(n * 64 * sizeof(*evr)), 0, n * 64 * sizeof(*evr));alloca() никак не сигнализирует о нехватке памяти; кроме того, возвращаемое значение не проверяется.

А вот так писать можно:
rpmds sourceDs = memset(alloca(sizeof(*sourceDs)), 0, sizeof(*sourceDs));
При этом 2-я конструкция используется в коде повсеместно, похоже, 1-я была написана ради "единообразия кода". Таким образом при просмотре можно пропустить переменную n.

Повторяю, это ошибка элементарная и очевидная (повезло, что сделана не намеренно). Она прошла как раз на территорию РФ, не в Альт, а другую систему.

Исправление для ошибки с переполнением стека:
diff -pNaur rpm-rosa.orig/lib/psm.c rpm-rosa/lib/psm.c
--- rpm-rosa.orig/lib/psm.c 2017-12-06 16:44:00.000000000 +1000
+++ rpm-rosa/lib/psm.c 2017-12-06 19:17:32.499534079 +1000
@@ -1904,7 +1904,8 @@ static rpmRC runScriptTriggersLoop(rpmps
     rpmfi fi = NULL;
     rpmds sourceDs = memset(alloca(sizeof(*sourceDs)), 0, sizeof(*sourceDs));
     char * depName = NULL;
-    char * evr;
+    char * evr = NULL;
+    char * evr_allocated = NULL;
     char * ptr = NULL;
     ARGI_t instances = NULL;
     rpmmi mi;
@@ -1920,15 +1921,26 @@ static rpmRC runScriptTriggersLoop(rpmps
     else
  n = ts->orderCount;
 
-    evr = memset(alloca(n * 64 * sizeof(*evr)), 0, n * 64 * sizeof(*evr));
-    ptr = evr;
     sourceDs->tagN = tagno;
     sourceDs->Type = tagName(tagno);
     sourceDs->Count = n;
     sourceDs->i = -1;
-    sourceDs->N = memset(alloca(n * sizeof(*sourceDs->N)), 0, n * sizeof(*sourceDs->N));
-    sourceDs->EVR = memset(alloca(n * sizeof(*sourceDs->EVR)), 0, n * sizeof(*sourceDs->EVR));
-    sourceDs->Flags = (evrFlags *) memset(alloca(n * sizeof(*sourceDs->Flags)), 0, n * sizeof(*sourceDs->Flags));
+
+    /* Avoid stack allocation as it overflows */
+    rc = RPMRC_FAIL;
+    ptr = evr = evr_allocated = calloc(n * 64, sizeof(*evr));
+    if (!evr_allocated)
+ goto exit_free;
+    sourceDs->N = calloc(n, sizeof(*sourceDs->N));
+    if (!sourceDs->N)
+ goto exit_free;
+    sourceDs->EVR = calloc(n, sizeof(*sourceDs->EVR));
+    if (!sourceDs->EVR)
+ goto exit_free;
+    sourceDs->Flags = calloc(n, sizeof(*sourceDs->Flags));
+    if (!sourceDs->Flags)
+ goto exit_free;
+    rc = RPMRC_OK;
 
     pi = rpmtsiInit(ts);
     while ((p = rpmtsiNext(pi, psm->goal == PSM_PKGINSTALL ? TR_ADDED : TR_REMOVED)) != NULL) {
@@ -1957,7 +1969,7 @@ static rpmRC runScriptTriggersLoop(rpmps
     pi = rpmtsiFree(pi);
 
     if (sourceDs->i == -1)
- return rc;
+ goto exit_free;
 
     /* Fire elements against rpmdb trigger strings. */
     for(sourceDs->i = 0; sourceDs->i < (int)sourceDs->Count; sourceDs->i++) {
@@ -1968,7 +1980,7 @@ static rpmRC runScriptTriggersLoop(rpmps
 
 
  if (!depName || !*depName)
-     return rc;
+     goto exit_free;
 
  if (_psm_debug)
      rpmlog(RPMLOG_DEBUG, "--> %s:%d depName: %s tagno: %d ix: %d\n", __FUNCTION__, __LINE__, depName, tagno, sourceDs->i);
@@ -2014,6 +2026,12 @@ static rpmRC runScriptTriggersLoop(rpmps
 
     instances = argiFree(instances);
 
+exit_free:
+    free(sourceDs->Flags);
+    free(sourceDs->EVR);
+    free(sourceDs->N);
+    free(evr_allocated);
+
     return rc;
 }
 
(по ссылке в системе регистрации ошибок всё на английском, поскольку в той "российской ОС" так принято).

Оффлайн АлексеМиК

  • Начинающий
  • *
  • Сообщений: 13
  • Христос воскресе - воистину воскресе Христос
    • Страница в ВК устраивает
Рискнул. Обновился до последних версий и ядра и прикладного ПО p10.
Все работает. Из изменений заметил только либрофис 7.2 вместо 7.1 и файрфокс 91.7 вместо 91.6
Не обновлялся с 24/02/2022 Рождества Христова в связи с ну вы поняли...
НО По датам пакетов заметил что большинство сформированы (я правильное слово подобрал?? поправьте если ошибся)
до 24/02.2022 Рождества Христова. Я давно в СПО. Помню еще времена когда приходилось ./configure make make install
По тем временам не ностальгирую
Слава Богу
А вайбер не ставьте
Во имя Отца и Сына и Святаго Духа!

Оффлайн trs

  • Давно тут
  • **
  • Сообщений: 240
* sys-kernel/vanilla-sources
     Доступные версии:
     (4.9.311) (~)4.9.311^bs
     (4.14.276) (~)4.14.276^bs
     (4.19.239) (~)4.19.239^bs
     (5.4.190) (~)5.4.190^bs
     (5.10.112) [M](~)5.10.112^bs
     (5.15.35) [M](~)5.15.35^bs
     (5.17.4) [M](~)5.17.4^bs

/var/db/repos/gentoo/profiles/package.mask
# Mike Pagano <mpagano@gentoo.org> (2022-04-26)
# These kernels contain a major regression that causes power button
# to stop working, apparently making it impossible to leave suspend
# on some laptops without a (difficult) hard reset.

[M] рядом с номером версии означает запрет на установку. Причина в комментарии ниже. Из-за регрессии ядра некоторые ноутбуки не включаются без приседаний и плясок с бубном. Дальше смотреть "некогда". Здесь же "некогда" аргумент?

Оффлайн АлексеМиК

  • Начинающий
  • *
  • Сообщений: 13
  • Христос воскресе - воистину воскресе Христос
    • Страница в ВК устраивает
У меня версия ядра 5.10.110
Полет нормальный (слава Господу!!!!)
Не лень переставить если что систему с флехи (не дай Бог) но смогу если что.
Во имя Отца и Сына и Святаго Духа!