The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

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

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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


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

73. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +8 +/
Сообщение от Аноним (73), 17-Июл-21, 13:11 
Дружище ходить к психологу в момент кризиса - не стыдно.
Ответить | Правка | Наверх | Cообщить модератору

88. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +5 +/
Сообщение от Аноним (88), 17-Июл-21, 14:31 
Но дорого
Ответить | Правка | Наверх | Cообщить модератору

109. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +5 +/
Сообщение от Урри (ok), 17-Июл-21, 18:24 
И бессмысленно.
Ответить | Правка | Наверх | Cообщить модератору

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

89. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +2 +/
Сообщение от нах.. (?), 17-Июл-21, 15:09 
А мы тут тогда зачем?
Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +3 +/
Сообщение от Аноним (1), 17-Июл-21, 01:07 
Ты второй, я третий. Четвёртый ответит снизу.
Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +9 +/
Сообщение от Аноним (39), 17-Июл-21, 03:21 
Звали?
Ответить | Правка | Наверх | Cообщить модератору

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

78. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Другой аноним (?), 17-Июл-21, 13:33 
Да в повершел то поди умеет :)
Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

172. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Мамкин Хакер (?), 19-Июл-21, 19:53 
Книгу снаружи и раньше протирал дезин.салфеткой, а сейчас еще 3-4 недели "вылеживается", и если листаю в первые дни - потом руки мыть с мылом.
Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от Аноним (25), 17-Июл-21, 00:24 
Никто не мешает его форкнуть, это же СПО.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

70. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +3 +/
Сообщение от OpenEcho (?), 17-Июл-21, 12:56 
Угу... можо самому тоже мотор в машине перебрать, сантехнику дома отремонтировать, газ самому протянуть, до че там говорить, можно самому ультра лайт самолет построить...
Жизь, она ведь ведь резиновая, учи все подряд и делай все сам, на все время хватит...
Ответить | Правка | Наверх | Cообщить модератору

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

90. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от нах.. (?), 17-Июл-21, 15:11 
Дети не нужны, только ресурсы сьедают.
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (54), 17-Июл-21, 11:10 
В uBlock есть продвинутый режим, который покрывает немалую часть возможностей uMatrix:
https://addons.cdn.mozilla.net/user-media/previews/full/238/...
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

76. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от ананоша (?), 17-Июл-21, 13:28 
Успешно переехал на ублок, для кук заюзал чистилку. Если хочется удалять куки из запроса перед отправкой, надо искать дополнение, это не задача ублока
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

94. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от Мамкин Хакер (?), 17-Июл-21, 16:12 
В правой графе - для этого, в левой - для всех (квадратик красный, да)
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

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

6. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (6), 16-Июл-21, 22:02 
удваиваю вопрос. Очень странно что у такой нужной штуки не завелось популярного форка
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

41. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от КО (?), 17-Июл-21, 06:28 
NoScript в первую очередь нужные элементы показывает, остальное дерьмо и счетчики как раз на Ublock  и настройки браузера
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от Аноним (18), 16-Июл-21, 23:05 
Двачую.

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

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

А Issues и Pull Requests!

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –8 +/
Сообщение от Хан (?), 16-Июл-21, 22:07 
Утечка памяти на JS? У него же есть сборщик мусора
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от Аноним (13), 16-Июл-21, 22:22 
ну так кол-во ещё нужного мусора становится слишком много
и всё, капут
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

124. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (124), 17-Июл-21, 23:09 
Его не приглашают
Ответить | Правка | Наверх | Cообщить модератору

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

34. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +8 +/
Сообщение от username (??), 17-Июл-21, 01:30 
Что за глупости? Сборщик мусора занимается освобождением неиспользуемых ресурсов, а тут о таком речи не идёт, только рекурсия. То есть все эти данные мусором не являются с точки зрения движка, потому что используются
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

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

123. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +3 +/
Сообщение от Аноним84701 (ok), 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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

117. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –4 +/
Сообщение от Хан (?), 17-Июл-21, 19:22 
Размер стека статический, как утечка васян?
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

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

125. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Хан (?), 17-Июл-21, 23:13 
Я тут уже 10 лет лол
Ответить | Правка | Наверх | Cообщить модератору

127. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от Аноним (124), 17-Июл-21, 23:15 
Значит просто постарел
Ответить | Правка | Наверх | Cообщить модератору

126. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (124), 17-Июл-21, 23:13 
А откуда взялось слово "утечка"?
В новости не нашлось.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (53), 17-Июл-21, 10:58 
Ну, например, CPython валит на стек процессора.
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

87. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (53), 17-Июл-21, 14:22 
import sys
sys.setrecursionlimit(100500)
def fuuuu(): fuuuu()
fuuuu()
Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от n00by (ok), 17-Июл-21, 15:15 
И где там стек процессора?
Ответить | Правка | Наверх | Cообщить модератору

101. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (53), 17-Июл-21, 17:08 
sapienti sat
Ответить | Правка | Наверх | Cообщить модератору

106. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от n00by (ok), 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 подтверждения его утверждению -- он заблуждается. Это его забота.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

181. "Уязвимость в 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
Хотя и есть некоторые нюансы и в вызовах и в хранени локальных переменных

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Хватит рассуждать о теорвере, покажи код, где стек JS-машины адресуется через rsp. Вот как в моём примере, который я привёл от нечего делать: https://www.opennet.dev/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. И всё поймёшь. Особенно про "аргументы извлекаться" когда "адрес возврата остаётся".

Ответить | Правка | Наверх | Cообщить модератору

184. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Lex (??), 21-Июл-21, 15:34 
>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>> разы ты славно попадался на подмене понятий )
> Потому что у тебя проблемы с памятью https://www.opennet.dev/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]

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

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

Ответить | Правка | Наверх | Cообщить модератору

185. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от n00by (ok), 22-Июл-21, 13:40 
>>> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
>>> разы ты славно попадался на подмене понятий )
>> Потому что у тебя проблемы с памятью https://www.opennet.dev/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 идиотом и пустозвоном в одном лице.

Ответить | Правка | Наверх | Cообщить модератору

115. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от n00by (ok), 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й

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

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

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

144. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от pavlinux (ok), 18-Июл-21, 19:05 
......  
Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

46. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (46), 17-Июл-21, 08:31 
А что мешает потечь циклу? Да ничего не мешает. В грамотных руках он потечет даже лучше рекурсии.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

56. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от пох. (?), 17-Июл-21, 11:15 
не потечь, а просто оказаться бесконечным. Ну или достаточно длинным чтобы сожрать всю память.

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

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

Ответить | Правка | Наверх | Cообщить модератору

69. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от n00by (ok), 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);

Ответить | Правка | Наверх | Cообщить модератору

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


Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

Ответить | Правка | Наверх | Cообщить модератору

92. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от n00by (ok), 17-Июл-21, 15:38 
Там даже начали доказывать, что массив -- это правильно. https://www.opennet.dev/openforum/vsluhforumID3/124763.html#140
Ответить | Правка | Наверх | Cообщить модератору

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

121. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от НяшМяш (ok), 17-Июл-21, 21:23 
С сайтом всё нормально, это аноним не в порядке
Ответить | Правка | Наверх | Cообщить модератору

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

30. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от KT315 (ok), 17-Июл-21, 00:49 
Есть готовый и проверенный список или днс сервер?
Ответить | Правка | Наверх | Cообщить модератору

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

107. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +1 +/
Сообщение от Аноним (107), 17-Июл-21, 18:13 
Кому ты врёшь? К тебе никто никогда не приходит в гости.
Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

17. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от Аноним (17), 16-Июл-21, 23:04 
Чем оно лучше adblock?
Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (27), 17-Июл-21, 00:36 
Тем, что работает, в отличие от.
Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –4 +/
Сообщение от Анон123амм (?), 17-Июл-21, 16:29 
ничем))) зато на отличненько ломает дофига страниц, в отличии от адблока.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

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

19. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (19), 16-Июл-21, 23:16 
Народ а как его обновить? не настройках не нашел нечего подобного. Ну кроме как удалить и заново поставить
Ответить | Правка | Наверх | Cообщить модератору

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

79. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +2 +/
Сообщение от ананоша (?), 17-Июл-21, 13:36 
Докатились - учим на опенете как обновлять расширения в брузере
Ответить | Правка | Наверх | Cообщить модератору

83. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от пох. (?), 17-Июл-21, 13:50 
> Докатились - учим на опенете как обновлять расширения в брузере

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

49. "Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"  +/
Сообщение от Аноним (46), 17-Июл-21, 08:36 
Странно даже что ты смог до такого сам догадаться. Макровирусы пока что никто не отменял и бороться с ними в данном случае имеено бразуер. И даже дам спойлер. Никакой раст от этого не спасет.
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

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

62. "Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"  –1 +/
Сообщение от Total Anonimus (?), 17-Июл-21, 12:17 
Вспоминается и сколько воплей из за запрета расширениям валить браузер , из за которого многократно упомянутое всуе Расширение полностью перестаёт работать . "Ужас , хром с блокировщиками борется !!!"
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

157. "Уязвимость в uBlock Origin, приводящая к краху или исчерпанию ресурсов"  –1 +/
Сообщение от kai (??), 19-Июл-21, 02:55 
Ты бы новость почитал. Там не само расширение сжирает память, а страница, которую расширение рендерит
Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +7 +/
Сообщение от Kuromi (ok), 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);

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

Ответить | Правка | Наверх | Cообщить модератору

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

48. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (46), 17-Июл-21, 08:33 
Под видом уязвимости выпиливают фичи!
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

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

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

47. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –4 +/
Сообщение от Аноним (46), 17-Июл-21, 08:32 
Да все понятно все эти юблоки, шмублоки надо делать отдельной тулзой написано на нормальных языках, с машинным обучением рекламы и вот этим вот всем. А не просто плагином на веселеньком языке.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

(ц) 2006

Ответить | Правка | Наверх | Cообщить модератору

51. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от Аноним (52), 17-Июл-21, 10:25 
Например что для хорошего ИИ нужна видюха Nvidia с CUDA желательно последней модели. Которую на Линуксе ты никогда не настроишь как надо потому что дров нет как и Игорей.
Ответить | Правка | Наверх | Cообщить модератору

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

63. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –3 +/
Сообщение от Аноним (64), 17-Июл-21, 12:24 
Если ты про проприетарное ненужно, то ставь эти зонды себе сам знаешь куда.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (5), 17-Июл-21, 12:47 
Ты, например, понимаешь, что, допустим, любые карты, идут с, тащем-то, шифрованными блобами? Если, допустим, например, говорить, например, об обеспечении работоспособности железа у, скажем, покупателей, например, то, допустим, проприетарная модель, скажем, вполне уместна.
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

143. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от Аноним (5), 18-Июл-21, 16:10 
Так проблемы вейланда. Я лично сравнивал на glx и игры opengl, и эмуляторы, и бенчмарки, всегда одинаковая производительность.
Ответить | Правка | Наверх | Cообщить модератору

146. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от iPony129412 (?), 18-Июл-21, 19:18 
Так не работает в реальном мире, что проблема одной стороны, а другой до лампочки...
Точнее работает, но в итоге получается плохо.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

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

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

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

Версия 1.36.3b5

Ответить | Правка | Наверх | Cообщить модератору

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

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

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


Ответить | Правка | Наверх | Cообщить модератору

120. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от пох. (?), 17-Июл-21, 19:47 
> Вот так нихрена не работает.

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

145. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –1 +/
Сообщение от pavlinux (ok), 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"]

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

118. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –2 +/
Сообщение от Хан (?), 17-Июл-21, 19:24 
Че за бред... как может быть учечка памяти в сцуко статическом стеке? Это не куча... тупо понятия путают, называя переполнение стека утечками... уровень информатики 10 класса
Ответить | Правка | Наверх | Cообщить модератору

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

140. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  –3 +/
Сообщение от Хан (?), 18-Июл-21, 15:25 
А фраза наблюдается исчерпание памяти в Firefox это што?
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

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

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

Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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


Ответить | Правка | Наверх | Cообщить модератору

175. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (174), 20-Июл-21, 00:00 
Что ты несешь? Отдельные потоки не только в Firefox, но и даже в js через workers уже 100 лет есть. И ограничить им возможность жрать память это нормально.
Ответить | Правка | Наверх | Cообщить модератору

178. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от n00by (ok), 20-Июл-21, 08:53 
Поток - это то что исполняется. Процесс -- это адресное пространство, где исполняется поток. Если упрощённо.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

Ответить | Правка | Наверх | Cообщить модератору

182. "Уязвимость в uBlock Origin, приводящая к краху или исчерпани..."  +/
Сообщение от Аноним (182), 20-Июл-21, 16:10 
Хаха, опять javascript. У растоманов рушится мир
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру