В Chrome и ChromeOS обнаружены уязвимости

Какие виджеты??? Это же отдельные проги за отрисовку которых отвечает лаунчер... О_о

У меня ни один виджет из тех которые я запускал не пропал...

Я что-то не догоняю, походу, либо ты ошибаешься...

Это значит, что прога штатно завершится, вызвав все деструкторы и прочее, в то время, как C++ упадёт сразу или позволит некоторое время читать чужую память.

Это значит, что прога штатно завершится, вызвав все деструкторы и прочее, в то время, как C++ упадёт сразу или позволит некоторое время читать чужую память.

память чужого процесса никто тебе читать не позволит, расслабься

Это значит, что прога штатно

стоооой, погоди. ты пост читал, который комментируешь?

Да. Пост об уязвимостях, которые rust предотвращает.

Пост об уязвимостях, которые rust предотвращает

последний раз спрашиваю: ты пост который комментируешь читал и понимаешь о чем там идёт речь, или не читал/не понимаешь, а просто увидел знакомые слова?

ты лучше задумайся-ка. я не просто так спрашиваю. задумайся, почему возникло CVE-2017-5054. о чем там идёт речь, а не просто реагируй на знакомые слова «переполнение буфера». я ссылку на описание проблемы давал в самом начале треда. даже намекну: «переполнение буфера» в этом баге это не переполнение буфера в самом V8. а в чём?

Если софт правильный, его любая свинья съюзает... :-)

Причина может быть любой. Факт в том, что в rust переполнение буфера обрабатывается по-другому.

В OpenBSD -current уже обновился Chromium в портах.
Тарболл исходников 57.0.2987.133 для тех у кого ещё не прилетело обновление Chromium здесь, в Gentoo кстати адаптировать существующий ебилд просто.

ВНЕЗАПНО!!!!! Почему никто не пишет, что это настоящее решето.

внезапно, баг довольно странный.

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

а вот тут выкинулась проверка но не выкинулась ветвь исполнения. ассемблерная инструкция

mov    DWORD PTR [eax*4+0xa521b98],0x12345678

m32[((1-ff(NaN) >>> 0) % 0xdc4e153) & v] = 0x12345678;

я слабо представляю, как нормальными оптимизациями добиться появления такой константы.

ты хочешь нам сказать, что если бы V8 был написан на расте с сохранением логики 1-в-1, этой уязвимости не было?

нука расскажи нам, как ржавый поможет от подобных ошибок. на примере CVE-2017-5054

Так «от ошибок, подобных приведенным в посте» или «от ошибок, подобных CVE-2017-5054»?

Я не читал ваши потуги, но в заголовке buffer overflow, который в раст устроен по-другому.

конкретно от 5054. предположим, что нам завезли идеального ржавого, в котором нет изъянов и он компилится в абсолютно безопасный код. как этот ржавый спасет от 5054?

вот именно что. как собака павлова - увидел в заголовке buffer overflow и всё понял.

а потом таким программистам С++ в шаровары срёт.

По делу есть что сказать?

почитай тред. а, я забыл. слишком сложно.

Я повторю свой вопрос.

Конкретно от 5054 - никак. Но половина багов в хедпосте - банальные выходы за границы, от которых идеальный ржавый спасет. И от использования после освобождения он тоже спасет - точнее, заставит писать программу так, чтобы такого использования не было.

А ведь годный-то браузер что сказать.

Всё же очевидно! v8 должен генерить не асм-код, а код на расте. Заодно получит и переносимость.

Это недолеченный баг, которым фбр пользовался? Или интегрированный код для слежки?

об обновлении стабильного канала браузера Chrome

Что за канал? Особенности перевода?

stable, beta, dev...

Да, перевод немного некорректен.
Надо было перевести как «канала обновлений»

скажем так - не обязательно это злой умысел, но рукожопия там выше крыши. Например, я не понимаю, как вообще такой ассемблерный код мог образоваться.

Код, который крахается собственно, если его разобрать до вида, которым оперирует кодогенератор, должен выглядеть так:

int __var1 = (toInt(1-ff(NaN) >>> 0) % 0xdc4e153); //const - вычислить в compile time
int __var2 = __var1 & v; //not const 
if (uint(__var2) > m32.lenght) //non-const vs const - выкинуть нельзя!
   throw ...
m32[__var2] = 0x12345678; //вот тут крах

m32 = это ссылка на некий буфер. она не const. т.е. я ожидал бы увидеть команду mov [4*reg + reg] = 0x12345678, где первый reg = __var2, а второй - адрес данных в буфере m32. а вместо этого мы видим mov [4*reg + const] = 0x12345678;

это как вообще? я конечно могу предполжить, что они держат внутренее один массив m32 на весь хип, и новые массивы просто мапают поверх него.

[global m32========[my m32]=====[another m32]=====]

во вторых, как уже я говорил, у них явно различаются правила по которым считает оптимизатор и правила по которым считает javascript. но не ожидал что там всё так плохо:

Fix typing rule for Math.sign.
         case kMathSign:
-          return t->cache_.kMinusOneToOne;
+          return t->cache_.kMinusOneToOneOrMinusZeroOrNaN;

(1-ff(NaN) >>> 0) % 0xdc4e153

(castToInt(1-ff(NaN)) >>> 0) % 0xdc4e153

Опять же, там math.Sign от константы и ссылка на него тоже константна, и сама функция без side effectов. Не смогли его вычислить на месте? какая разница что там за typing rule, просто вычисли его блжадь и замени Sign(NaN)->NaN. И так далее по цепочке. Так все делают - gcc, llvm и таких проблем у них нет и быть не может.

То что они удалили проверку выхода за границы говорит о том, что они отслеживают как возможные диапазоны значений, так и возможные значения битов(0,1,unknown). В общем, стараются. Но вот свести саму константу не могут почему-то.

Хорошая новость, столько уязвимостей исправлено