URL: https://ssl.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 124820
[ Назад ]

Исходное сообщение
"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"

Отправлено opennews , 16-Июл-21 21:36 
В системе блокирования нежелательного контента uBlock Origin выявлена уязвимость, позволяющая добиться краха или исчерпания памяти при навигации по специально оформленному URL, в случае подпадания данного URL под фильтры строгой блокировки ("strict blocking"). Уязвимость проявляется только при прямом переходе на проблемный URL, например при клике по ссылке...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55498


Содержание

Сообщения в этом обсуждении
"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 21:36 
Уязвимости на уязвимости, уязвимостью погоняет. Даже я стал уязвим. Если раньше от такой новости смеялся, то сейчас если бы я прекратил ржать, я бы заплакал.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 13:11 
Дружище ходить к психологу в момент кризиса - не стыдно.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 14:31 
Но дорого

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Урри , 17-Июл-21 18:24 
И бессмысленно.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 11:45 
Судя по твоим предыдущим комментариям, тебя стоит посадить в псих.диспансер. Конечно, обычный визит к психологу для тебя бесполезен, а вот хороший психиатр накачает тебя лекарствами, чтобы больше опеннет не видовал твоих шизофренических потугов.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено нах.. , 17-Июл-21 15:09 
А мы тут тогда зачем?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 21:41 
Молодцы. Уделали. Смогли. Серьезно, очень круто. Надеюсь им дадут премии.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 16-Июл-21 21:42 
"В ηMatrix, форке uMatrix от проекта Pale Moon, уязвимость устранена в выпуске 4.4.9." Вот только это форк XUL версии, для ФФ не подходит. Чертовски жаль что Юматрикс бросили, ибо возвращаться на куда менее функциональный (по сути) НоСкрипт не хочется.

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 16-Июл-21 22:53 
> можно закрыть дырку портированием туда фикса, руками

для этого надо уметь кодить, это не про аудиторию опеннета.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Тинус Лорвальдс , 17-Июл-21 00:47 
>для этого надо уметь кодить, это не про аудиторию опеннета.

ты первый в этом списке.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 01:07 
Ты второй, я третий. Четвёртый ответит снизу.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 03:21 
Звали?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 19-Июл-21 11:08 
Не. Спи дальше.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Другой аноним , 17-Июл-21 13:33 
Да в повершел то поди умеет :)

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 16:45 
вот, кстати, не угадал, них...я. ctrl-c/ctrl-v со стека не считается.
Посоветуйте какую-нибудь толковую книжку "powershell для неудачников, застрявших в развитии на  tcl" ? ("Для альтернативно-одаренных" не надо - у меня не получается заставить себя воспринимать ТАКОЕ.)

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Мамкин Хакер , 17-Июл-21 17:32 
Bertram Adam PowerShell for Sysadmins может? не читал но а...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 19:32 
> Bertram Adam PowerShell for Sysadmins может? не читал но а...

"keeps crashing my Kindle every time" - хорошая книжка, надо брать! ;-)


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Мамкин Хакер , 19-Июл-21 19:53 
Книгу снаружи и раньше протирал дезин.салфеткой, а сейчас еще 3-4 недели "вылеживается", и если листаю в первые дни - потом руки мыть с мылом.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 00:24 
Никто не мешает его форкнуть, это же СПО.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено OpenEcho , 17-Июл-21 12:56 
Угу... можо самому тоже мотор в машине перебрать, сантехнику дома отремонтировать, газ самому протянуть, до че там говорить, можно самому ультра лайт самолет построить...
Жизь, она ведь ведь резиновая, учи все подряд и делай все сам, на все время хватит...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 13:57 
Правильной дорогой идёте товарищ... стоп а делать детей вы тоже кому то делегируете?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено нах.. , 17-Июл-21 15:11 
Дети не нужны, только ресурсы сьедают.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено OpenEcho , 20-Июл-21 14:05 
> Дети не нужны, только ресурсы сьедают.

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 11:10 
В uBlock есть продвинутый режим, который покрывает немалую часть возможностей uMatrix:
https://addons.cdn.mozilla.net/user-media/previews/full/238/...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено BSD_Cucks_BTFO , 17-Июл-21 11:51 
То есть, я либо блокирую все 3rd party скрипты, либо все разрешаю? А как с одного третьего домена заблокировать скрипты, а с другого разрешить? А fetch-запросы он умеет ограничивать/разрешать на определённые домены?
И с куками этот "продвинутый" режим, как я понимаю, вообще не работает? Как разрешить куки с одних 3rd party, а с других запретить?
В umatrix всё вышеперечисленное делается в пару кликов. Не говоря уже о намного более удобном и понятном интерфейсе.
Динамический режим блокирования в ublock вообще никакая не замена umatrix, к сожалению.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 12:07 
> я либо блокирую все 3rd party скрипты, либо все разрешаю?

нет, те же белые/черные списки.

>  Как разрешить куки с одних 3rd party, а с других запретить?

через ublock origin никак


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено ананоша , 17-Июл-21 13:28 
Успешно переехал на ублок, для кук заюзал чистилку. Если хочется удалять куки из запроса перед отправкой, надо искать дополнение, это не задача ублока

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Мамкин Хакер , 17-Июл-21 16:12 
В правой графе - для этого, в левой - для всех (квадратик красный, да)

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 21:56 
Забавно конечно, однако ublock реже нужен чем umatrix. Чё делать, альтернатив то нет?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 22:02 
удваиваю вопрос. Очень странно что у такой нужной штуки не завелось популярного форка

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено InuYasha , 16-Июл-21 22:06 
Таки, с ублоком больше шансов увидеть говносайт, а не рандомный набор кусков элементов или "уупс, вы устарели, переходите на могилу". А уматрикс - надо оооооооооооооооооо(skipped 1024 bytes)ооочень долго настраивать (так же как в своё время RequestPolicy, PoliceMan).

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 22:09 
> Таки, с ублоком больше шансов увидеть говносайт, а не рандомный набор кусков
> элементов или "уупс, вы устарели, переходите на могилу". А уматрикс -
> надо оооооооооооооооооо(skipped 1024 bytes)ооочень долго настраивать (так же как в своё
> время RequestPolicy, PoliceMan).

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено InuYasha , 16-Июл-21 22:12 
Вот и сидишь часами, разбирая, где телеметрия, а где 4 разных 1С-цдн-а у очередного сраного магазина, которому ещё нужен goolag-api, xepnЯ-maps, sber-anal-rape и облачный битрикс.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено КО , 17-Июл-21 06:28 
NoScript в первую очередь нужные элементы показывает, остальное дерьмо и счетчики как раз на Ublock  и настройки браузера

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 18-Июл-21 03:43 
> NoScript в первую очередь нужные элементы показывает, остальное дерьмо и счетчики как
> раз на Ublock  и настройки браузера

NoScript Сильно сдал после перехода на WebExt. Хоть Маоне и приложил усилия, но первые релизы были просто непригодны, а потом хоть и стало съедобно но все таки уже не то. Я в свое время ушел на юМатрикс потому что на Ночнушках NoScript тсал глючить неимоверно. Обычно Маоне держит нос по ветру, а тут чето нет. При этом у юМатрикса проблем с Ночнушкой не было вообще, хотя работают они на одном и том же принципе.
Но вот, чтож, похоже NoScript всех пережил, причем не первый раз уже.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 23:05 
Двачую.

Те, кто "вот и сидишь часами" по видимому от страха даже пробовать не будут, и даже не узнают, как там на самом деле. Если они боятся, что им может быть гипотетически необходимо сидеть часами, для себя любимого, значит они недостойны защиты. Значит если разрабу нужного им сайта станет костью в горле umatrix и он сделает так, чтобы при нём ничего не работало, наворотит обфусцированного кода, то они просто прогнутся, вместо того чтобы посидеть часами, всё разреверсить, наваять обход и проучить м**илу.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Ищооо , 17-Июл-21 02:22 
Когда сидишь на паре одноглазников - можно и над настройками посидеть , за компанию . А если до бабсканаскамейкеуподьезда возраста не дожил и активно серфишь - тратить полжизни на настройки влом .

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 13:31 
Вообще почта тоже бывает загажена антиублочными скриптами со случайными именами, и вот их то umatrix/nmatrix убивают успешно. Этих *удаков много, как будто мы им обратно им в задницу не засунем их проклятую рекламу с зондами.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 17-Июл-21 00:31 
> Забавно конечно, однако ublock реже нужен чем umatrix. Чё делать, альтернатив то
> нет?

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 08:05 
Не надо закрывать. Надо наоборот оставить. Я бы на месте автора сделал следующее: открыл бы там issue, называющую дедлайн удаления проекта из githubа и AMO. Кто не форкнул/утянул master до удаления - автор не виноват! При настулении дедлайна - взять и удалить. Никто не форкнул - ну значит не нужно, никто из людей от удаления не пострадал. Кто-то форкнул и объявил себя преемником - ну и флаг ему в руки.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 11:25 
> пострадал. Кто-то форкнул и объявил себя преемником - ну и флаг
> ему в руки.

Чувак, вынужден огорчить - нажатие кнопочки "fork" на шитхабе не создает настоящий форк, создается только бесполезный клон. Который сам себя не обновит и не починит.

Для этого надо уметь кодить.

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Андрей , 17-Июл-21 16:10 
> Кто не форкнул/утянул master до удаления

А Issues и Pull Requests!


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 18-Июл-21 03:47 
> Не надо закрывать. Надо наоборот оставить. Я бы на месте автора сделал
> следующее: открыл бы там issue, называющую дедлайн удаления проекта из githubа
> и AMO. Кто не форкнул/утянул master до удаления - автор не
> виноват! При настулении дедлайна - взять и удалить. Никто не форкнул
> - ну значит не нужно, никто из людей от удаления не
> пострадал. Кто-то форкнул и объявил себя преемником - ну и флаг
> ему в руки.

Неужели? А что же тогда Реймонд не удалил uMatrix из AMO? Вот оно, лежит, всем доступно - https://addons.mozilla.org/en-US/firefox/addon/umatrix/
В описании даже НИ СЛОВА что разработка и поддержна прекращены. Обычный пользователь кстати в Гитхаб не ходит, он с AMO, а то и прямо из about:addons ставит расширения.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 18-Июл-21 09:23 
> Неужели? А что же тогда Реймонд не удалил uMatrix из AMO? Вот

чтобы не создали левый экстнш с "освободившимся" названием.
История с ublock показала, что м-ков хватает.

> В описании даже НИ СЛОВА что разработка и поддержна прекращены. Обычный пользователь

"это дубли у нас простые". Обычный пользователь не ставит уматриксов, он не знает, ни зачем ему это ненужно, ни как им пользоваться.

А необычные - сами виноваты.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 16-Июл-21 22:07 
Утечка памяти на JS? У него же есть сборщик мусора

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 22:22 
ну так кол-во ещё нужного мусора становится слишком много
и всё, капут

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 22:43 
>и всё, капут

Сборщик мусора спину срывает?


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 23:09 
Его не приглашают

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 20:17 
В V8 мусор собирается каждые N секунд. В Хроме я только один раз смотрел, тогда было 10 секунд. И зависит от сколько свободно ОЗУ и нагрузки на ЦП. Если бы моментально мусор собирался, то тогда загрузка страниц дольше.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено username , 17-Июл-21 01:30 
Что за глупости? Сборщик мусора занимается освобождением неиспользуемых ресурсов, а тут о таком речи не идёт, только рекурсия. То есть все эти данные мусором не являются с точки зрения движка, потому что используются

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 17-Июл-21 19:21 
Подожди, утечка памяти это выделение памяти в куче, то что ты говоришь это переполнение стека... какая может быть в стеке утечка памяти если она не выделяется?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним84701 , 17-Июл-21 22:09 
>> these parameters were parsed recursively and added to the DOM without any depth checks, which could lead to extension crashes and memory exhaustion,
> Подожди, утечка памяти это выделение памяти в куче, то что ты говоришь  это переполнение стека...

man чтение_не_только_заголовка


> какая может быть в стеке утечка памяти если она не выделяется?
> если она не выделяется?

man paging


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 17-Июл-21 23:19 
Всмысле? Что мне задвигаешь? Утечка памяти это когда программа забивает своими данные ВСЮ СВОБОДНУЮ ОПЕРАТИВНУЮ ПАМЯТЬ СИСТЕМЫ

Переполнение стека возникает когда в СТЕК запихивают данных больше чем он может уместить

Мало того, что природа этих ошибок разная так еще и завершаются они по разному, утечка памяти в целом не критична, а вот переполнение стека это немедленное аварийное завершение программы на уровне процессора


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним84701 , 17-Июл-21 23:47 
> Подожди, утечка памяти это выделение памяти в куче, то что ты говоришь это переполнение стека...
> Всмысле? Что мне задвигаешь?

Сам что-то придумал про стек, сам что-то оспорил ...

> Утечка памяти это когда программа забивает своими данные
> ВСЮ СВОБОДНУЮ ОПЕРАТИВНУЮ ПАМЯТЬ СИСТЕМЫ
> Переполнение стека возникает когда в СТЕК запихивают данных больше чем он может уместить

Сам себе придумал свое определение утечки, сам себе что-то доказал ...

> Мало того, что природа этих ошибок разная так еще и завершаются они
> по разному, утечка памяти в целом не критична,

Сам придумал, что рекурсивно вызываемая процедура не может жрать память на куче, сам ...

> какая может быть в стеке утечка памяти если она не выделяется?
> а вот переполнение стека это немедленное аварийное завершение программы на уровне процессора

*всеясно.жпг*


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 17-Июл-21 19:22 
Размер стека статический, как утечка васян?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 22:03 
Может тебе сменить ник на "Хам"? На форуме без году 2 недели, а уже своим хамством весь форум замусорил, что ни один сборщик мусора не разгребёт.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 17-Июл-21 23:13 
Я тут уже 10 лет лол

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 23:15 
Значит просто постарел

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 23:13 
А откуда взялось слово "утечка"?
В новости не нашлось.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено InuYasha , 16-Июл-21 22:10 
Любите рекурсию? Тогда мы идём к вам.
Хотя, наверное, рекламу хеbнR без рекурсивных регулярных выражений и не урежешь... (а раньше хватало простого ЭдБлока со звёздочками и вопросиками)

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 00:20 
_любая_ рекурсия может быть переписана в виде цикла.

А уж когда речь о разборе информации с сайта, который нам сказали _заблокировать_нахрен_...


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 03:11 
Ну будет вместо бесконечной рекурсии бесконечный цикл, сильно поможет?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Lex , 17-Июл-21 05:25 
В случае с рекурсией огромное количество данных валится в стек, тогда как в случае с циклом - можно весьма просто это подправить..
Тем более, ничего не мешает при достижении энных размеров, завершать обработку с сигналом «слишком толсто».. и с циклом это сделать сильно проще.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 07:52 
> В случае с рекурсией огромное количество данных валится в стек

На самом деле данные "стека" валятся в кучу и количество их не "огромно". Попробуете напишите интерпретатор, который бы "валил" данные в стек процессора, что бы иметь представление о вопросе.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 10:58 
Ну, например, CPython валит на стек процессора.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 12:40 
> на пример

Не вижу примера.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 14:22 
import sys
sys.setrecursionlimit(100500)
def fuuuu(): fuuuu()
fuuuu()

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 15:15 
И где там стек процессора?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 17:08 
sapienti sat

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 17:55 
Вот типичная работа со стеком виртуального процессора, исполняется инструкция RETURN:

    Instruct(RETURN): {
      sp += *pc++;
      if (extra_args > 0) {
        extra_args--;
        pc = Code_val(accu);
        env = accu;
      } else {
        pc = (code_t)(sp[0]);
        env = sp[1];
        extra_args = Long_val(sp[2]);
        sp += 3;
      }
      Next;
    }

А вот как выглядит часть реализации исполнителя команд той же ВМ, которая использует аппаратный стек:

Instruct    RETURN
    mov    eax, [opcode.1]
    next_opcode
    lea    rsp, [rsp + rax * sizeof value]
    test    extra_args, extra_args
    jnz    .extra_args
    pop    vm_pc
    pop    env
    pop    extra_args
    Long_val extra_args
    Instruct_next
.extra_args:
    dec    extra_args
    jmp    Instruct_APPTERM1.br
end Instruct

Если кому не понятно, то sp это просто имя переменной-указателя, адресует выделенную по malloc() память. А rsp это регистр процессора. ЯВУ с регистрами без специальных приседаний не работают, и если кто-то полезет в стек при помощи alloca(), то к нему возникнут вопросы.

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Lex , 17-Июл-21 12:48 
При вызове функции, в стек падает адрес возврата + все передаваемые аргументы( строки итп - указателями ).
При работе вызванной функции, аргументы могут извлекаться( редко, обычно к ним напрямую обращаются через esp или [esp-n]. Но адрес возврата в любом случае остаётся. Итого, уже не менее 4байт для 32-битных и 8 байт - для 64-битных систем соотв на каждый вызов функции без аргументов и локальных переменных - и это только для возврата ).

Локальные переменные, явные или неявные, обычно тоже лежат в стеке( как минимум, в виде указателей )


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 12:59 
> При вызове функции, в стек падает адрес возврата + все передаваемые аргументы(
> строки итп - указателями ).

Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?

> При работе вызванной функции, аргументы могут извлекаться( редко, обычно к ним напрямую
> обращаются через esp или [esp-n].

Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы. Да, тут надо хоть малость понимать, что такое стек процессора и куда он растёт.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Lex , 17-Июл-21 18:42 
Мистер не в курсе, что жс движки уже лет сто как с джИтом, а не примитивные только_интерпретаторы( поначалу да, код именно интерпретируется, но часто исполняемые функции «компилируют» для улучшения производительности ) ?

Дык ты код сишной программы в дизассемблере открой да посмотри.
Аргументы в функции обычно передаются через стек, только некоторые на стороне вызываемой функции достают данные из стека, подчищая его, а другие - работают напрямую с указателем на стек, итогом чего становится ускоренное загаживание стека на адрес возврата + все передаваемые аргументы( как минимум, их указатели ).
Можешь даже онлайн-преобразователями что-то -> асм воспользоваться типа:
https://godbolt.org/

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 18:52 
Алёша, я не удивлён, что ты своё утверждение доказать не можешь. Ты уже был пойман на пустозвонстве. Наличие JIT не является достаточным условием.

И ладно бы ты признал, что ошибся со знаком смещения от регистра стека, тогда бы с тобой имело бы смысл продолжать разговор. Но ты ведь дальше зарываешься. Так даже Криска Касперски не загонялся, пока его не вразумили. Правда, его с тобой сравнивать не уместно. Он, как минимум, умел писать и текстами зажечь.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Lex , 20-Июл-21 15:02 
Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие разы ты славно попадался на подмене понятий )

Кстати, о пустозвонстве..
> Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?

Помнишь ?
Ты ведь фундаментально не прав, ведь там и далеко не только интерпретатор и сгенерированный код к стеку проца имеет самое прямое отношение. Но.. признался ли хоть в чем-то ?)

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

> что ошибся со знаком смещения от регистра стека,

Возможно, кому-то стоит меньше придираться к мелочам если есть что сказать по сути. Так меньше шансов оказаться невеждой( притом, невоспитанным ).

Так ошибся ли ? Или просто ты не понял что к чему ?
*подмигивание* А ведь ты так и не доказал не_использования стека для хранения локальных переменных или ссылок на них.. даже не просто не доказал, но и сделал вид что этого нет..

Так.. как бы ты со своей колокольни объяснил РЕАЛЬНЫЙ "выхлоп" clang'а( хотя и у гцц примерно то же самое ) а не то что у тебя в голове со стеком творится ? :

int testFunc( int arg ) {
    int tmp1 = 123;
    int tmp2 = 456;
    return tmp1 * arg;
}

push    rbp
mov     rbp, rsp
> Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы

// ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
mov     dword ptr [rbp - 4], edi
// Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
mov     dword ptr [rbp - 8], 123
// Ребяят, ну хватит уже!
mov     dword ptr [rbp - 12], 456
mov     eax, dword ptr [rbp - 8]
// Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
imul    eax, dword ptr [rbp - 4]
pop     rbp
ret


> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)

Это все здорово кнчн, но что если аргументов будет больше чем регистров ?) -Ну это к слову о не_использовании стека.
Тем более, что мире существует далеко не только линух со своими соглашениями о вызовах( хотя и в 32-битном линуховом очень даже применялся стек )

Но, да, в общем и целом на х86_64 передача аргументов стала получше
Часто данные передаются через регистры, а что не влезло - через стек против cdecl и stdcall
Хотя и есть некоторые нюансы и в вызовах и в хранени локальных переменных


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 20-Июл-21 17:02 
> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
> разы ты славно попадался на подмене понятий )

Потому что у тебя проблемы с памятью https://www.opennet.ru/openforum/vsluhforumID3/124773.html#51 (заметь, что пруфы просил не я, я их за тебя предоставил; но там малость неувязка по срокам санкций, длиною в треть твоей жизни), при этом ты очень хорошо умеешь в "а нас то за шо?", что как бэ намекает.

> Кстати, о пустозвонстве..
>> Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?
> Помнишь ?
> Ты ведь фундаментально не прав, ведь там и далеко не только интерпретатор
> и сгенерированный код к стеку проца имеет самое прямое отношение. Но..
> признался ли хоть в чем-то ?)

Я прав в том, что сам ты ничего в данном направлении не сделал, нахватался по верхам и теперь пытаешься натянуть какое-то выдуманное тобой "там" на абстрактную JIT-компиляцию. Если бы ты создал интерпретатор и подумал над тем, как согласовать с существующей ВМ (про сборщик мусора замнём для ясности) сгенерированный на лету машинный код, ты бы сам дошёл: избавляться в нём от стека ВМ означает "иметь два стека", что накладно и нецелесообразною.

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

Хватит рассуждать о теорвере, покажи код, где стек JS-машины адресуется через rsp. Вот как в моём примере, который я привёл от нечего делать: https://www.opennet.ru/openforum/vsluhforumID3/124820.html#106

>> что ошибся со знаком смещения от регистра стека,
> Возможно, кому-то стоит меньше придираться к мелочам если есть что сказать по
> сути. Так меньше шансов оказаться невеждой( притом, невоспитанным ).

Суть вопроса проста. Кто утверждение заявляет, тот его и подтверждает. Данный случай не тот, где приходится принимать слова на веру. Если JS машины что-то валят в аппаратный стек, значит есть код, который это делает. Мне интересно на этот код посмотреть.

> Так ошибся ли ? Или просто ты не понял что к чему
> ?
> *подмигивание* А ведь ты так и не доказал не_использования стека для хранения
> локальных переменных или ссылок на них.. даже не просто не доказал,
> но и сделал вид что этого нет..

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

>[оверквотинг удален]
> int testFunc( int arg ) {
>     int tmp1 = 123;
>     int tmp2 = 456;
>     return tmp1 * arg;
> }
> push    rbp
> mov     rbp, rsp
>> Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы
> // ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ
> аргумент ?)

Это называется - пролог функции и формирование стекового кадра. Поскольку указатель стека в теле функции меняется, проще адресовать стек через регистр базы стека. При этом значение ebp сохраняется (по конвенции оно неизменно для вызывающей стороны). В прошлом веке компиляторы так делали, поскольку были далеки от совершенства. Ныне это бессмысленная операция, если не считать упрощения отладки.

> mov     dword ptr [rbp - 4], edi
> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)

Да, это локальная переменная, потому и смещение -- отрицательное. В ней сохранён переданный через регистр edi аргумент.

> mov     dword ptr [rbp - 8], 123
> // Ребяят, ну хватит уже!
> mov     dword ptr [rbp - 12], 456

Действительно, хватит выдавать локальные переменные подпрограммы за её аргументы.

> mov     eax, dword ptr [rbp - 8]
> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))

Нет, это локальная переменная tmp1.

> imul    eax, dword ptr [rbp - 4]

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

> pop     rbp
> ret

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

Вот как должен был выглядеть твой пример:

gcc arg.c -S -fverbose-asm -masm=intel -o arg.s


testFunc:
.LFB0:
    .cfi_startproc
    push    rbp    #
    .cfi_def_cfa_offset 16
    .cfi_offset 6, -16
    mov    rbp, rsp    #,
    .cfi_def_cfa_register 6
    mov    DWORD PTR -20[rbp], edi    # arg, arg
# arg.c:2:    int tmp1 = 123;
    mov    DWORD PTR -8[rbp], 123    # tmp1,
# arg.c:3:    int tmp2 = 456;
    mov    DWORD PTR -4[rbp], 456    # tmp2,
# arg.c:4:    return tmp1 * arg;
    mov    eax, DWORD PTR -8[rbp]    # tmp84, tmp1
    imul    eax, DWORD PTR -20[rbp]    # _4, arg
# arg.c:5: }
    pop    rbp    #
    .cfi_def_cfa 7, 8
    ret

И предпочти изучать код после оптимизатора, это поможет понять, как работает транслятор:

gcc arg.c -O2 -S -fverbose-asm -masm=intel -o arg.s


testFunc:
.LFB0:
    .cfi_startproc
# arg.c:4:    return tmp1 * arg;
    imul    eax, edi, 123    # tmp84, tmp85,
# arg.c:5: }
    ret

>> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
> Это все здорово кнчн, но что если аргументов будет больше чем регистров
> ?) -Ну это к слову о не_использовании стека.

Для этого в скобочках и написано, что надо посмотреть.

> Тем более, что мире существует далеко не только линух со своими соглашениями

Здесь Линукс является системой по умолчанию. Архитектуру процессора ты выбрал сам, я лишь её актуализировал.

> о вызовах( хотя и в 32-битном линуховом очень даже применялся стек
> )

Ну вот и посмотрел бы, как именно он применялся, вместо эффектных попыток продемонстрировать свою базу.

Пока получается в стиле "сделайте это за меня".
Вот так передаются параметры процессу (тут немного лишнего, но оставлю как есть):


_start:
;    Допустим 1 аргумент - имя файла байт-кода.
    mov    rcx, [rsp]    ; argc
    cmp    ecx, 2
    jz    .1arg
    puts    error_about
    mov    edi, -EINVAL
    jmp    sys_exit
.1arg:    mov    rdi, [rsp + 16]    ; argv
    mov    [bytecode_filename], rdi
;    Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
;    слов после argv (rsp + 8)
    lea    rdx, [rsp + 8 + (rcx + 1) * 8]
    mov    [environment_variables], rdx

> Но, да, в общем и целом на х86_64 передача аргументов стала получше
> Часто данные передаются через регистры, а что не влезло - через стек
> против cdecl и stdcall
> Хотя и есть некоторые нюансы и в вызовах и в хранени локальных
> переменных

Это всё не имеет отношения к вопросу смещения. Просто подумай как следует, что в каком порядке складывается на стек в случае stdcall и почему помимо retn есть вариант с аргументом retn 8. И всё поймёшь. Особенно про "аргументы извлекаться" когда "адрес возврата остаётся".


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Lex , 21-Июл-21 15:34 
>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>> разы ты славно попадался на подмене понятий )
> Потому что у тебя проблемы с памятью https://www.opennet.ru/openforum/vsluhforumID3/124773.html#51
> (заметь, что пруфы просил не я, я их за тебя предоставил;
> но там малость неувязка по срокам санкций, длиною в треть твоей
> жизни), при этом ты очень хорошо умеешь в "а нас то
> за шо?", что как бэ намекает.

И в чем конкретно ложь ?
Заодно и на себя сошлись со своим не_бу_а_списанным_оборудованием, которое у тебя вдруг синонимом стало )

> Я прав в том, что сам ты ничего в данном направлении не сделал

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

>[оверквотинг удален]
>> ?
>> *подмигивание* А ведь ты так и не доказал не_использования стека для хранения
>> локальных переменных или ссылок на них.. даже не просто не доказал,
>> но и сделал вид что этого нет..
> Это называется -- переложить бремя доказательства на оппонента. Приём демагогии такой.
> Мне не требуется что-либо опровергать, поскольку исходное твоё утверждение голословно.
> Тем не менее, скажу по секрету. Пример, на который я выше
> дал ссылку (2й фрагмент), как раз это и делает. Но к
> вопросу отношения не имеет. И я не знаю, как бы его
> к нему прикрутить.

Ты неправильно разобрал даже простейший предоставленный мной пример функции на сях и на асме с комментариями, у тебя вдруг то включалась избирательная слепота, то - отключалась память и ты забывал, НАД целевой строкой написан коммент или ПОД ней [хотя как позже оказалось ты и сам пишешь комменты НАД целевой строкой. Т.е ты даже про свои привычки забывал]
Так.. как и почему в свете этого можно верить твоей кодовой чепухе, которую ты называешь "доказательством" чего-то ?

>> ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
>> mov     dword ptr [rbp - 4], edi
>> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
>> mov     dword ptr [rbp - 8], 123
>> ...
>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>> imul    eax, dword ptr [rbp - 4]

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

>> mov     eax, dword ptr [rbp - 8]
>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
> Нет, это локальная переменная tmp1.
>> imul    eax, dword ptr [rbp - 4]
> А вот здесь как раз и должна была быть попытка выдать желаемое
> за действительное, но автор в горячке перепутал строчки.

Тебя ведь вовсе не смутило, что везде комменты написаны НАД комментируемой строкой( даже ты сам, как оказалось, именно так пишешь ), а не ПОД ней, не так ли ?)

Ну что, будешь и дальше самосливаться и разводить демагогию со своими:
Не_может_быть_отрицательных_смещений_применительно_к_стеку [может]
Это именно опечатка [нет, не опечатка]
Сейчас_аргументы_функций_в_стеке_не_хранятся [хранятся. Только теперь их туда на вызываемой стороне заталкивают, а не на вызывающей как раньше, если нельзя жестоко соптимизировать]
Вместо честного признания, что дуб-дубом и просто нахватался верхов прежде, чем хотя бы глянуть функцию в дизасме ?

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

Хотя мог бы просто промолчать по поводу отрицательных смещений и "опечатки со знаком" и показался бы умным и культурным человеком. А не дубом и демагогом, не способным признать собственные очевидные ошибки и пытающимся изо всех сил сменить тему.

>> pop     rbp
>> ret
> Возьми за правило указывать ключи транслятора, когда публикуешь листинг. Это поможет тебе
> самому избежать ряд ошибок.
> Вот как должен был выглядеть твой пример:
> gcc arg.c -S -fverbose-asm -masm=intel -o arg.s

Только я на clang'е собирал, о чем выше упоминал. Ну куда уж заморачиваться о таких мелочах избирательно-слепому, не так ли ?
Поначалу, кстати, хотел с гнутого дизасм, но там смещения не так лаконично смотрелись. Если сравнишь с моим( шланг ) - увидишь, что -20 там нет - смещения идут красиво аккурат на размер указателя/значения_переменной ( 4, 8, 12 против 20,  8, 4 )

>> mov     dword ptr [rbp - 4], edi
>> mov     dword ptr [rbp - 8], 123
>> mov     dword ptr [rbp - 12], 456

// выше - шланговский. Все ровненько, по 4 байта

> mov    DWORD PTR -20[rbp], edi
> mov    DWORD PTR -8[rbp], 123
> mov    DWORD PTR -4[rbp], 456

// выше - твой, гнутый

// Твой полный выхлоп дизасма
> testFunc:
> .LFB0:
> .cfi_startproc
> и еще куча текста и ненужных директив

Я тебе предоставил максимально компактный листинг чтобы пост не засорять
>>>> Можешь даже онлайн-преобразователями что-то -> асм воспользоваться типа:
>>>> https://godbolt.org/

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

> И предпочти изучать код после оптимизатора, это поможет понять, как работает транслятор:

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

И вот, снова несешь какую-то чепуху, теперь про "оптимизатор", хотя тебя вовсе не смущает, что ты "героически" собрал с оптимизациями код, рассчитанный на максимальную простоту, наглядность и компактность, оттого и собираемый БЕЗ оптимизации( иначе - придется делать пример сильно сложнее, постить горы текста, а итог будет тем же - нормальность отрицательных смещений, хранение данных локальных переменных в стеке, как и аргументов функции, обращение к ним через отрицательное смещение стека и твоя откровенная невежественность, как и неспособность признать свою неправоту )

> gcc arg.c -O2 -S -fverbose-asm -masm=intel -o arg.s
>

 
> testFunc:
> .LFB0:
>  .cfi_startproc
> # arg.c:4:    return tmp1 * arg;
>  imul eax, edi, 123 # tmp84, tmp85,
> # arg.c:5: }
>  ret
>

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

>>> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
>> Это все здорово кнчн, но что если аргументов будет больше чем регистров
>> ?) -Ну это к слову о не_использовании стека.
> Для этого в скобочках и написано, что надо посмотреть.

Как !? Ты вывалил гору мусора вплоть до примера передачи аргументов в (!) процесс но поленился сказать несколько слов по теме ?)

>> Тем более, что мире существует далеко не только линух со своими соглашениями
> Здесь Линукс является системой по умолчанию. Архитектуру процессора ты выбрал сам, я
> лишь её актуализировал.

Здесь - это у тебя в голове ? На сайте полно людей и с виндой, и с бздей.. и с яблоком немало.

>> о вызовах( хотя и в 32-битном линуховом очень даже применялся стек
>> )
> Ну вот и посмотрел бы, как именно он применялся, вместо эффектных попыток
> продемонстрировать свою базу.

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

> Пока получается в стиле "сделайте это за меня".
> Вот так передаются параметры процессу (тут немного лишнего, но оставлю как есть):

троллейбус_из_буханки.jpg

Серьезно, зачем тут это, если речь о вызываемых функциях, локальных переменных и стеке, а не о передаче параметров процессу ?

> ; Допустим 1 аргумент - имя файла байт-кода.
>  mov rcx, [rsp] ; argc
> ...
>  mov [bytecode_filename], rdi
> ; Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
> ; слов после argv (rsp + 8)
>  lea rdx, [rsp + 8 + (rcx + 1) * 8]

Кстати, забавная ситуация. Ты тоже пишешь комменты НАД комментируемой строкой..
Теперь у меня совсем нет идей, почему в случае с предоставленным мной кодом ты ИНОГДА смотрел на строку, которая была НАД комментом а не под ним и нес чепуху исходя из этого.
Хотя и была мысль, что ты пишешь комменты под целевой строкой и, по привычке, так же начал смотреть в чужой код.. но очевидно нет. Это просто твой очередной косяк.

Ну что, признаешь, что был неправ практически во всем, начиная от моей "опечатки" с отрицательным смещением стека, нахождению аргументов функции в стеке( теперь их туда заталкивают на стороне вызываемой функции, а не вызывающего.. но обращение к ним в итоге все так же в основном через стек ) и вплоть до исключительно_одного_интерпретатора в современном жс( и следующей из этого не_относимости_жс_кода к реальному пробу и стеку ) ?


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 22-Июл-21 13:40 
>>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>>> разы ты славно попадался на подмене понятий )
>> Потому что у тебя проблемы с памятью https://www.opennet.ru/openforum/vsluhforumID3/124773.html#51
>> (заметь, что пруфы просил не я, я их за тебя предоставил;
>> но там малость неувязка по срокам санкций, длиною в треть твоей
>> жизни), при этом ты очень хорошо умеешь в "а нас то
>> за шо?", что как бэ намекает.
> И в чем конкретно ложь ?

Пустозвонство, это когда тебя попросили привести пруфы, но ты их не предоставил. Сейчас ты подменил "пустозвонство" на "ложь". Это немного разные вещи.

> Заодно и на себя сошлись со своим не_бу_а_списанным_оборудованием, которое у тебя вдруг
> синонимом стало )

Уймись уже с этим "а нас за шо?" Исключительный нашёлся.

>> Я прав в том, что сам ты ничего в данном направлении не сделал
> Нет бы по честному признаться, что от души обделался с исключительно_интерпретатором в
> жс и отсутствием реального исполнения кода на процессоре - нет же,
> маню включаешь.
> Хотя, что от тебя еще ожидать..

Чуешь запашок из шаровар? Это потому что ты не показал код, который генерирует JIT.

>[оверквотинг удален]
>>> локальных переменных или ссылок на них.. даже не просто не доказал,
>>> но и сделал вид что этого нет..
>> Это называется -- переложить бремя доказательства на оппонента. Приём демагогии такой.
>> Мне не требуется что-либо опровергать, поскольку исходное твоё утверждение голословно.
>> Тем не менее, скажу по секрету. Пример, на который я выше
>> дал ссылку (2й фрагмент), как раз это и делает. Но к
>> вопросу отношения не имеет. И я не знаю, как бы его
>> к нему прикрутить.
> Ты неправильно разобрал даже простейший предоставленный мной пример функции на сях и
> на асме с комментариями, у тебя вдруг то включалась избирательная слепота,

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

> то - отключалась память и ты забывал, НАД целевой строкой написан
> коммент или ПОД ней [хотя как позже оказалось ты и сам
> пишешь комменты НАД целевой строкой. Т.е ты даже про свои привычки
> забывал]
> Так.. как и почему в свете этого можно верить твоей кодовой чепухе,
> которую ты называешь "доказательством" чего-то ?
>>> ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ аргумент ?)
>>> mov     dword ptr [rbp - 4], edi

Да хоть в межушный ганглий он пусть "заталкивается". Это происходит после вызова. Передан он в регистре.

>>> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
>>> mov     dword ptr [rbp - 8], 123
>>> ...
>>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>>> imul    eax, dword ptr [rbp - 4]
> Выше, как видишь, кусок предоставленного мной кода с комментами.

Вижу, Алёша упорно называет аргументом локальную переменную, где временно хранится значение аргумента, который был передан в регистре edi, а не через стек.

>>> mov     eax, dword ptr [rbp - 8]
>>> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
>> Нет, это локальная переменная tmp1.
>>> imul    eax, dword ptr [rbp - 4]
>> А вот здесь как раз и должна была быть попытка выдать желаемое
>> за действительное, но автор в горячке перепутал строчки.
> Тебя ведь вовсе не смутило, что везде комменты написаны НАД комментируемой строкой(
> даже ты сам, как оказалось, именно так пишешь ), а не
> ПОД ней, не так ли ?)

Тюююашотакова. Шо, с тобой нельзя поступать зеркально?

>[оверквотинг удален]
> и демагогом, не способным признать собственные очевидные ошибки и пытающимся изо
> всех сил сменить тему.
>>> pop     rbp
>>> ret
>> Возьми за правило указывать ключи транслятора, когда публикуешь листинг. Это поможет тебе
>> самому избежать ряд ошибок.
>> Вот как должен был выглядеть твой пример:
>> gcc arg.c -S -fverbose-asm -masm=intel -o arg.s
> Только я на clang'е собирал, о чем выше упоминал. Ну куда уж
> заморачиваться о таких мелочах избирательно-слепому, не так ли ?

Выше Алёша писал "хотя и у гцц примерно то же самое", но ныне у него склероз. GCC с -fverbose-asm  явственно комментирует, что аргумент пришёл в регистре и создаётся его копия:

mov    DWORD PTR -20[rbp], edi    # arg, arg

Потому Алёша старательно этот нюанс выкидывает и забалтывает.

> Серьезно, зачем тут это, если речь о вызываемых функциях, локальных переменных и
> стеке, а не о передаче параметров процессу ?

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

>[оверквотинг удален]
>> ; Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
>> ; слов после argv (rsp + 8)
>>  lea rdx, [rsp + 8 + (rcx + 1) * 8]
> Кстати, забавная ситуация. Ты тоже пишешь комменты НАД комментируемой строкой..
> Теперь у меня совсем нет идей, почему в случае с предоставленным мной
> кодом ты ИНОГДА смотрел на строку, которая была НАД комментом а
> не под ним и нес чепуху исходя из этого.
> Хотя и была мысль, что ты пишешь комменты под целевой строкой и,
> по привычке, так же начал смотреть в чужой код.. но очевидно
> нет. Это просто твой очередной косяк.

Да, это мой косяк: я связался со старательно не замечающим + 8 + (rcx + 1) * 8 идиотом и пустозвоном в одном лице.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 19:05 
> Аргументы в функции обычно передаются через стек

Нет, Алёша, это так было обычно, когда ты в школе на уроке истории книжку Зубкова читал. Лет десять-пятнадцать уже всё немного не так:

; Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
;
; Сохраняются при вызовах внешних функций: RBX RBP RSP R12 R13 R14 R15
;
; Параметры передаются в регистрах:
; RDI    1й
; RSI    2й
; RDX    3й
; RCX    4й    ; R10 для вызовов ядра
; R8    5й
; R9    6й

Впрочем, это не имеет отношения к вопросу, который ты так и не доказал.

Это я на всякий случай публикую, вдруг кому интересно.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено pavlinux , 18-Июл-21 19:05 
......  

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 18:45 
> аргументы могут извлекаться
> Но адрес возврата в любом случае остаётся

Вот это, кстати, пёрл редкостного качества. Вроде как есть у человека какое-то представление, но суть перевёрнута с ног на голову. И ведь мог бы, прежде чем писать эту чушь, хотя бы картинки посмотреть. Примечательно, что именно такие и топят за Rosa Tresh.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 11:19 
> Тем более, ничего не мешает при достижении энных размеров, завершать обработку с
> сигналом «слишком толсто».. и с циклом это сделать сильно проще.

в принципе, одинаково, но при написании цикла гораздо быстрее осознаешь, что да, надо добавлять ограничитель.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 07:41 
> _любая_ рекурсия может быть переписана в виде цикла.

Так точно. Только это не имеет отношения к вопросу. В данном случае "рекурсия" относится не только к реализации алгоритма, где на каждой итерации цикла происходит выделение памяти: li.appendChild(ul);


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 08:31 
А что мешает потечь циклу? Да ничего не мешает. В грамотных руках он потечет даже лучше рекурсии.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 11:15 
не потечь, а просто оказаться бесконечным. Ну или достаточно длинным чтобы сожрать всю память.

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

Особенно, когда рекурсия не в твоем коде, а, как в данном случае, скрыта внутри regexp.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 12:50 
> Особенно, когда рекурсия не в твоем коде, а, как в данном случае,
> скрыта внутри regexp.


diff --git a/src/js/document-blocked.js b/src/js/document-blocked.js
index 08b2fd732972..b0034ef3ae87 100644
--- a/src/js/document-blocked.js
+++ b/src/js/document-blocked.js
@@ -144,7 +144,9 @@ uDom.nodeFromId('why').textContent = details.fs;
         return s;
     };

-    const renderParams = function(parentNode, rawURL) {
+    // https://github.com/uBlockOrigin/uBlock-issues/issues/1649
+    //   Limit recursion.
+    const renderParams = function(parentNode, rawURL, depth = 0) {
         const a = document.createElement('a');
         a.href = rawURL;
         if ( a.search.length === 0 ) { return false; }
@@ -165,9 +167,9 @@ uDom.nodeFromId('why').textContent = details.fs;
             const name = safeDecodeURIComponent(param.slice(0, pos));
             const value = safeDecodeURIComponent(param.slice(pos + 1));
             const li = liFromParam(name, value);
-            if ( reURL.test(value) ) {
+            if ( depth < 2 && reURL.test(value) ) {
                 const ul = document.createElement('ul');
-                renderParams(ul, value);
+                renderParams(ul, value, depth + 1);
                 li.appendChild(ul);
             }
             parentNode.appendChild(li);


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 13:08 
надо ж, то есть тут регексп был обычный, честная рекурсия на функциях. Ну вот потому и не надо так делать. Особенно ради "depth <2", то есть оно вызывается ровно два раза. Даже цикл не нужен, одного вложенного if хватило бы. фуфуфу так кодить.



"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 13:20 
Ну если в _эталонной_ реализации вычисления числа Фибоначчи https://www.opennet.ru/opennews/art.shtml?num=55466
злоупотребляют массивом, когда достаточно 2-х переменных, то чего ещё ждать...

Здесь, возможно, глубину оставили, что бы потом поменять на 3 или 5.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 13:45 
ой ;-) return array[num] просто прекрасно.
Кстати, никто ж и не заметил что с этим кодом что-то не так ;-)


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 15:38 
Там даже начали доказывать, что массив -- это правильно. https://www.opennet.ru/openforum/vsluhforumID3/124763.html#140

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 16:50 
да, я уже просветился. Причем новость-то я читал, где были мои глаза, спрашивается, хотя, конечно, я даже не попытался понять что тот код делает, не это было интересно.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 22:10 
>В ηMatrix, форке uMatrix от проекта Pale Moon
>Pale Moon

Бррр, кокой ужос.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено НяшМяш , 16-Июл-21 23:27 
Сразу видно пользователя, который хотя бы раз офсайт открывал

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 12:26 
Лучше бы не открывал

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 13:46 
> Сразу видно пользователя, который хотя бы раз офсайт открывал

что не так с сайтом? Я уж подумал - линька опять началась, но нет, сайт как сайт.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено НяшМяш , 17-Июл-21 21:23 
С сайтом всё нормально, это аноним не в порядке

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Гоша7778 , 16-Июл-21 22:35 
Обновлю ublock. Делов то. А так все равно все заблочено на роутере по dns. Хрен какая дичь откроется даже если кто в гости придёт и я раздам ему wifi. Многие удивляются типо как так, в приложениях нет рекламы и в браузере.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено KT315 , 17-Июл-21 00:49 
Есть готовый и проверенный список или днс сервер?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Гоша7778 , 17-Июл-21 03:15 
В любом роутере уже поддерживается, в два клика. У меня diversion для Asus к примеру. Но есть также под openwrt, и другие прошивки. Есть как вариант pi-hole, под любой роутер, но тут надо ставить блокировку других dns кроме pi-hole, потому что куча приложений под сотики обходят это уже давно.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 18:13 
Кому ты врёшь? К тебе никто никогда не приходит в гости.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 23:04 
Чем оно лучше adblock?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 00:36 
Тем, что работает, в отличие от.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Анон123амм , 17-Июл-21 16:29 
ничем))) зато на отличненько ломает дофига страниц, в отличии от адблока.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено 123 , 17-Июл-21 16:53 
Тем, что имеет частично функционал uMatrix. У AdBlock Plus и им подобных такого нет. Как резалка рекламы и uBlock Origin и AdBlock Plus (и ему подобные) имеют примерно равный функционал.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 16-Июл-21 23:16 
Народ а как его обновить? не настройках не нашел нечего подобного. Ну кроме как удалить и заново поставить

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено НяшМяш , 16-Июл-21 23:38 
В лисе на странице дополнений кнопка с шестерёнкой -> проверить наличие дополнений. По-умолчанию там автообновление из магазина стоит.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено ананоша , 17-Июл-21 13:36 
Докатились - учим на опенете как обновлять расширения в брузере

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 13:50 
> Докатились - учим на опенете как обновлять расширения в брузере

херли ты ждал другого - из всей аудитории двое отметились что умеют кодить.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Аноним , 17-Июл-21 00:11 
Неправильно сформулирована новость.
Правильно было бы - разработчики системе блокирования нежелательного контента uBlock Origin выявили уязвимость в браузерах, позволяющую расширению добиться краха или исчерпания памяти в Chrome и Firefox.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Total Anonimus , 17-Июл-21 00:20 
Многие тысячи других расширений , в том числе и блокировщиков , подобного не вызывают . А сама новость имеет подтекст : додумались что взламывать можно не только браузеры ...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Имя , 17-Июл-21 01:20 
Как и многие миллионы страниц в интернете ничего подобного не вызывают. Что ни о чем не говорит.
По-нормальному, возможностей закрашить браузер у расширения должно быть не больше, чем у какого-нибудь криворуко слепленого говносайта.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Total Anonimus , 17-Июл-21 01:36 
То есть , это браузеры виноваты , что в одном расширение намертво зависает , а другой мусором забивает ? Понятненько .

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Аноним , 17-Июл-21 08:10 
Я тебе больше скажу. С помощью WebGL одно время можно было намертво завесить комп. Висло все намертво, ctrl+аlt+del не работал, только кнопка reset. Как сейчас - не знаю.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Аноним , 17-Июл-21 10:32 
С помощью баша можно уронить решительно любой сервер.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Аноним , 19-Июл-21 23:55 
Вот только баш это терминал, а js в браузере должен выполняться изолированно.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Аноним , 17-Июл-21 08:36 
Странно даже что ты смог до такого сам догадаться. Макровирусы пока что никто не отменял и бороться с ними в данном случае имеено бразуер. И даже дам спойлер. Никакой раст от этого не спасет.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Total Anonimus , 17-Июл-21 12:09 
Уже макровирусы и WebGL начали приплетать , лишь бы не признавать очевидное . С какой стати браузер должен бороться с данными , которые для него абсолютно легальны , но тупое расширение не может правильно обработать ? Хотя уже и так строгое выполнение фоксом стандартов csp - багом обозвали , раз юблок не справляется (в отличии от других) . Правильно - божество не может ошибаться , на костёр еретика . )))

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено Total Anonimus , 17-Июл-21 12:17 
Вспоминается и сколько воплей из за запрета расширениям валить браузер , из за которого многократно упомянутое всуе Расширение полностью перестаёт работать . "Ужас , хром с блокировщиками борется !!!"

"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено пох. , 17-Июл-21 13:12 
> Вспоминается и сколько воплей из за запрета расширениям валить браузер

мущина, вы уж определитесь, туда или сюда, а то туда-сюда, туда-сюда!

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Отправлено kai , 19-Июл-21 02:55 
Ты бы новость почитал. Там не само расширение сжирает память, а страница, которую расширение рендерит

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 17-Июл-21 00:43 
Итак, удя по вот этому коммиту - https://github.com/gorhill/uBlock/commit/b75921c2fd0a704e7c3...
Фикс - пару строчек заменить в /js/document-blocked.js
Смотрим внутряк uMatrix@raymondhill.net.xpi - видим там /js/main-blocked.js с сходным кодом в строке 89:

let renderParams = function(parentNode, rawURL) {
        let a = document.createElement('a');
        a.href = rawURL;
        if ( a.search.length === 0 ) { return false; }

и 111:
if ( reURL.test(value) ) {
                let ul = document.createElement('ul');
                renderParams(ul, value);

Вот здесь сосбтвенно и надо патчить, я так понимаю.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Kuromi , 17-Июл-21 01:26 
Правильно понимаю, похоже, т.к. бажный код был напрямую скопипащен в Юматрикс из юБлока - https://github.com/gorhill/uMatrix/commit/3f8168ce0bb7bb1837...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 08:33 
Под видом уязвимости выпиливают фичи!

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 17:00 
Да когда было иначе? Всегда так делают эти недобезопасники.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 17:21 
Надо запретить недобезопасников.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 08:32 
Да все понятно все эти юблоки, шмублоки надо делать отдельной тулзой написано на нормальных языках, с машинным обучением рекламы и вот этим вот всем. А не просто плагином на веселеньком языке.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 09:23 
> с машинным обучением рекламы и вот этим вот
> всем.

Мысль об ИИ, как и много лет назад,
все еще будоражит хэкерные умы и не дает покоя.

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

Что же мешает практической реализации этой замечательной (на наш взгляд) идеи?

Как правило, от создания ИИ (обычно) отвлекает школа и институт,
а также родители, включая неблагоприятное хэкерное субкультурное пространство.

- Володий! Вынес ли ты мусор? - кричит с кухни мама.
- Ну что, сынок, сдал ли сессию за прошлый год? - вопрошает по телефону отец.
- Троян-то как, готов уже? - донимают коллеги по хэкерному дзен-форуму.
- Немедленно верни общак! - открыто зоявляют одепты БХЦ.
- Какая оценка по математике была у вас в школе? - бросает мутный взгляд
учитель по мат-анализу, поправляя тяжелые очки и выбрасывая в мусорное ведро
разорванную пополам курсовую работу.
- Ты очень умный, но я люблю другого. Прощай. - говорит девушка.

Все это, вместе взятое, создает фатально невозможную для практической
реализации ИИ обстановку.

(ц) 2006


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 10:25 
Например что для хорошего ИИ нужна видюха Nvidia с CUDA желательно последней модели. Которую на Линуксе ты никогда не настроишь как надо потому что дров нет как и Игорей.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 11:12 
Простите, что? Фишечка NVIDIA например в том, что на линуксе CUDA работает совершенно без проблем. Тащем-то, как и всё остальное обычно, независимо от дистра. Вообще, например, допустим, например, игры в целом не основной рынок, и тащем-то, скажем, например, с играми на линуксе проблемы не из-за дров NVIDIA (эти как раз ничем не отличаются от вендовых, например).

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 12:24 
Если ты про проприетарное ненужно, то ставь эти зонды себе сам знаешь куда.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 17-Июл-21 12:43 
- Закончу ИИ в следующий раз. - с такими словами и тяжестью на сердце
выключает свой кампег хэкер, и уезжает по делам.

А в это время, на хэкерном форуме, сообщение об ИИ обрастает комментариями:

- Ты вобще представляешь себе сложность задасчи, которую ты перед собой ставишь?
- Сложность задачи - понятие субъективное. Есть какие нибудь идеи?
- Особенно если речь идет об интеллекте общго характера...
- ...возможно с выраженным напровлением выбора.
- Что вы вообще понимаете под интуицией?
- информация структурируется по ключевым словам...

На этом пожалуй все. А мы с вами переходим к следующей стотье.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 12:47 
Ты, например, понимаешь, что, допустим, любые карты, идут с, тащем-то, шифрованными блобами? Если, допустим, например, говорить, например, об обеспечении работоспособности железа у, скажем, покупателей, например, то, допустим, проприетарная модель, скажем, вполне уместна.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено iPony129412 , 17-Июл-21 13:40 
> из-за дров NVIDIA (эти как раз ничем не отличаются от вендовых, например).

Нет. Бред.
Конечно есть общая база, но всё равно — бред.

А со всеми этими иксами и вейландами сколько веселухи…


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 14:13 
Например, да, допустим, с точки зрения, например, приложения, там, тащем-то, совершенно одинаковые компиляторы шейдеров и, например, всё остальное. Тащем-то, всех различий там можно поискать в, скажем, WDDM/KMS, но, допустим, баги одни и те же будут на одном железе, как, например, и производительность, тащем-то.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено iPony129412 , 18-Июл-21 14:55 
> допустим, баги одни и те же будут на одном железе, как, например, и производительность, тащем-то.

Ну нет конечно. Всё по разному. Вон недавно статья на Phoronix была, что пару игр в два раза проседали в FPS в Wаylаnd сеансе.

В том числе можно посмотреть на изменение драйверов для Windows и Linux. Что ты увидишь в WIndows? Правильно - оптимизирована работа для игр таких-то.

То есть не смотря на некоторую общую базу, есть огромная куча нюансов и трах-бабахов.
И конечно приоритеты понятно какие по драйверам.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 16:10 
Так проблемы вейланда. Я лично сравнивал на glx и игры opengl, и эмуляторы, и бенчмарки, всегда одинаковая производительность.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено iPony129412 , 18-Июл-21 19:18 
Так не работает в реальном мире, что проблема одной стороны, а другой до лампочки...
Точнее работает, но в итоге получается плохо.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 19:32 
Проблема тут только с той стороны, что композитинг на вейланде не отключается. А это до 30% потери фпс на иксах (не на чем сравнить на вейланде, но я вижу просадки много где). Может быть, в этом дело. Кривые билды никто не отменял, опять же, но игры opengl в вайне всегда прекрасно работали. Если они работают в венде, то в линуксе они будут работать примерно так же или лучше. Это применимо только к NVIDIA,

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено iPony129412 , 19-Июл-21 05:10 
> Если они работают в венде, то в линуксе они будут работать примерно так же или лучше.

Нет. Практика это показывает.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено iPony129412 , 19-Июл-21 05:20 
> из-за дров NVIDIA (эти как раз ничем не отличаются от вендовых, например)

И тут само-собой про тот же Wayland - как это до сих пор так себе работает с nvidia.
Вот тебе и "ничем не отличается" - работать и работать над этим ещё надо. Как со стороны самих драйверов Nvidia, так и о стороны других разработчиков с линуксов.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 19-Июл-21 15:29 
С точки зрения софта, на линуксе есть только glx, а gles это мобильные платформы. Egl это абстракция и просто практически неюзабельно. Сам вейланд это мобильные платформы, не рабочие станции. Так что только иксы, да. Либо уже xwayland, только зачем столько лишних абстракций опять наворотили. С точки зрения приложения есть libgl которая примерно то же что под вендой. Только там через wgl, а тут glx. Примерно одно и то же и на производительность не влияет, по фичам не отличается и даже один один и тот же код использует (если верить диллеру), минорные отличия конечно имеются https://www.khronos.org/opengl/wiki/Platform_specifics:_Wind...

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 14:18 
> А со всеми этими иксами и вейландами сколько веселухи…

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


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Анон123амм , 17-Июл-21 16:25 
ЛОЛ, всегда говорил что это кривое поделие ненужно! Оно же и без уязвимостей ломает процентов 30% вебстраничек. Почему-то класический APB прекрасно отрабатывает в теж же условиях, отрезая рекламу ничего не сломав. А это чудо написаное школотой ужасно кривое.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 17:20 
Проблема явно в тебе раз у тебя APB все вырезает. И в тех сайтах на которые ты заходишь.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено pavlinux , 17-Июл-21 18:20 
> Уязвимость устранена в обновлении uBlock Origin 1.36.2.

Версия 1.36.3b5


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено pavlinux , 17-Июл-21 18:43 
Кстати, давно хотел спросить.
Есть сайт с рекламными гифками, имена у которых рандомны.

Прописывать правила вот так нет смысла
||ad.website.org/images/174e6db13dc73c066ae04f72f896c3e9.gif$image

Вот так нихрена не работает.
||ad.website.org/images/*.gif$image
||ad.website.org/images/*$image



"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 17-Июл-21 19:47 
> Вот так нихрена не работает.

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

> ||ad.website.org/images/*$image

afaik, * лишняя, это match (но ничему не мешает)

||cms-res.online.sberbank.ru/preloginbanners/$image - вполне избавляет меня от сберовской порнографии


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено pavlinux , 18-Июл-21 19:17 
>> Вот так нихрена не работает.
> открой лог и посмотри, почему. (подсказка: в нем есть фильтр)

У него лог есть? :D

> Возможо ты пооверрайтил сайт в rules?
>> ||ad.website.org/images/*$image
> afaik, * лишняя, это match (но ничему не мешает)
> ||cms-res.online.sberbank.ru/preloginbanners/$image - вполне избавляет
> меня от сберовской порнографии

Вот прям ощущение, что идейно GIF не хочет ловить.

---
В общем, только блокирование PHP внутори <DIV>  спасает.

forum.website.org###forum105 > .table.forumrow > .td.foruminfo > .forumdata > .datacontainer > div > [href^="https://ad.website.org/ad/www/delivery/ck.php"]


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 18-Июл-21 20:20 
о! А может этот gif и не image ниразу? А браузер тебе его все же показывает только из-за включенного автоугадава по имени файла вместо content-type?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено rust всё , 17-Июл-21 19:05 
казалось бы, при чём тут раст?

но JS - это "типа" безопасный язык, прямо как раст. и прямо как раст имеет заковыристые особенности языка. т.е. теоретически, роадмап для раста примерно схож с тем, что исторически происходит с JS.

выход тут только один: забыть про rust и обратиться к замечательному D!


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 17-Июл-21 19:24 
Че за бред... как может быть учечка памяти в сцуко статическом стеке? Это не куча... тупо понятия путают, называя переполнение стека утечками... уровень информатики 10 класса

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 17-Июл-21 23:31 
Нет там никакой утечки
Прочитай заголовок, потом новость

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 18-Июл-21 15:25 
А фраза наблюдается исчерпание памяти в Firefox это што?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 21:41 
Исчерпание - в ff аддон выделяет память, пока она не кончится.
В хромом выделяет до лимита песочницы. Хром прибивает дочерний процесс.
Не причем тут утечка, стек и куча?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Хан , 18-Июл-21 16:01 
С такой дэбильной формулировкой, можно и выход за пределы массива назвать исчерпанием памяти и даже целочисленное переполнение...

Но это же бред, ну бред же, бред....


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено rust всё , 19-Июл-21 09:02 
> С такой дэбильной формулировкой, можно и выход за пределы массива назвать исчерпанием
> памяти и даже целочисленное переполнение...
> Но это же бред, ну бред же, бред....

у тебя такое удивление.. будто ты никогда такого не видел. такое есть в любых языках, хоть в  си/сях++, хоть в py/go/rust


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 18-Июл-21 19:50 
Почему в FF происходит исчерпание памяти, а не просто крах процесса дополнения? Где изоляция?

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено пох. , 18-Июл-21 20:55 
> Почему в FF происходит исчерпание памяти, а не просто крах процесса дополнения?
> Где изоляция?

точно, каждому аддону - по процессу! Нет, лучше по пятнадцать!

Зато бебебебзопастно, бараны счастливы.



"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 20-Июл-21 00:00 
Что ты несешь? Отдельные потоки не только в Firefox, но и даже в js через workers уже 100 лет есть. И ограничить им возможность жрать память это нормально.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено n00by , 20-Июл-21 08:53 
Поток - это то что исполняется. Процесс -- это адресное пространство, где исполняется поток. Если упрощённо.

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 19-Июл-21 17:37 
УРА-А!!! Реймонд обновил uMatrix до версии 1.4.2 с устранением уязвимости.
https://github.com/gorhill/uMatrix/releases/tag/1.4.2

"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Тот самый , 19-Июл-21 20:28 
Ой, не надо торопиться с обновлением!

Там, похоже, проблемы большие. Например, у меня после обновления случайным образом стал глухо зависать FF. Помогает только отключение uMatrix. Версия 1.4.2 вышла несколько часов назад, а уже отрабатывается 1.4.3в0

Самое печальное, что откатиться обратно до 1.4.0 не получается - эта версия не имеет подписи мозиллы.

Лучше подождать более стабильного релиза.


"Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."
Отправлено Аноним , 20-Июл-21 16:10 
Хаха, опять javascript. У растоманов рушится мир