The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  вход/выход  слежка  RSS
"Критическая уязвимость в  OpenSSL 1.1.0a"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от opennews (ok) on 26-Сен-16, 17:46 
В изменениях, внесённых в опубликованном (https://www.opennet.ru/opennews/art.shtml?num=45195) на прошлой неделе обновлении криптографической библиотеки OpenSSL 1.1.0a, выявлена (https://mta.openssl.org/pipermail/openssl-announce/2016-Sept...) критическая уязвимость (CVE-2016-6309 (https://security-tracker.debian.org/tracker/CVE-2016-6309)), которая потенциально может привести к выполнению кода злоумышленника при обработке отправленных им пакетов.  Всем пользователям ветки OpenSSL 1.1.0 рекомендуется срочно обновить OpenSSL до версии 1.1.0b (https://mta.openssl.org/pipermail/openssl-announce/2016-Sept...). Уязвимость выявлена сотрудниками Google при проведении fuzzing-тестирования нового выпуска инструментом honggfuzz (https://github.com/google/honggfuzz).


Проблема присутствует в выпуске OpenSSL 1.1.0a в коде устранения уязвимости CVE-2016-6307 и проявляется при получении сообщения, размером больше 16 Кб, в ситуации перераспределения и перемещения буфера, отведённого для поступающих сообщений. Суть ошибки в том, что после перераспределения памяти остаётся
висячий указатель (https://ru.wikipedia.org/wiki/%D0%92%D0%...) на старое положение буфера и запись поступившего сообщения производится в ранее уже освобождённую область памяти. Наиболее вероятным результатом подобной записи будет крах, но разработчики не исключают нахождение векторов атаки, при которых возможно организовать выполнение кода атакующего.

Интересно, что это не единственная ошибка, допущенная в прошлых выпусках. В представленном 22 сентября обновлении прошлой ветки (OpenSSL 1.0.2i) всплыла менее опасная уязвимость (CVE-2016-7052 (https://security-tracker.debian.org/tracker/CVE-2016-7052)), в результате которой при попытке использования CRLs возникал крах из-за разыменования нулевого указателя. Проблема устранена в выпуске OpenSSL  1.0.2j.


URL: https://mta.openssl.org/pipermail/openssl-announce/2016-Sept...
Новость: https://www.opennet.ru/opennews/art.shtml?num=45215

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

Оглавление

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

1. "Критическая уязвимость в  OpenSSL 1.1.0a"  –11 +/
Сообщение от iZEN (ok) on 26-Сен-16, 17:46 
Почему в критически важных программах до сих пор используют указатели, а не проверяемые на этапе компиляции ссылки?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Онаним on 26-Сен-16, 17:47 
Фак.
Ну сколько можно так косячить...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от rt (??) on 26-Сен-16, 17:49 
> Проблема присутствует в выпуске OpenSSL 1.1.0a в коде устранения уязвимости CVE-2016-6307

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

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

4. "Критическая уязвимость в  OpenSSL 1.1.0a"  +9 +/
Сообщение от Аноним (??) on 26-Сен-16, 17:54 
Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Аноним (??) on 26-Сен-16, 18:25 
Как использование ссылок вместо указателей влияет на производительность?
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Критическая уязвимость в  OpenSSL 1.1.0a"  –10 +/
Сообщение от Аноним (??) on 26-Сен-16, 18:25 
Потому что C - это религия.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

7. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 26-Сен-16, 18:26 
> Почему в критически важных программах до сих пор используют указатели, а не
> проверяемые на этапе компиляции ссылки?

OpenSSL написан на сишечке, там ссылок нет

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

8. "Критическая уязвимость в  OpenSSL 1.1.0a"  +8 +/
Сообщение от Аноним (??) on 26-Сен-16, 18:28 
> а не проверяемые на этапе компиляции ссылки?

Проверяемые кем? Висячие ссылки не менее реальны, чем висячие указатели. И потом, работать ссылками с сырым буфером - это отдельное извращение.

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

9. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от KM on 26-Сен-16, 18:47 
> В RHEL/CentOS, Fedora и SUSE проблема не проявляется.

Кто там в соседней теме про "ха-ха" писал? ;)

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

10. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от eRIC (ok) on 26-Сен-16, 18:50 
Еще один факт, доказывающий что в OpenSSL некомпетентные люди пилят.
Вообще OpenSSL через разные утилиты прогонят и проверяют через профайлеры?

Мое предпочтение ИМХО LibreSSL и был бы рад когда FreeBSD перейдет на него по умолчанию как сделали это DragonFlyBSD.

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

11. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от YetAnotherOnanym (ok) on 26-Сен-16, 18:52 
Шикарная формулировка: "This security update addresses issues that were caused by patches included in our previous security update" - Данное обновление безопасности исправляет проблемы, вызванные патчами, включёнными в наше предыдущее обновление безопасности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 26-Сен-16, 18:57 
Ты дурак? OpenSSL написан на С, откуда там ссылки?
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

13. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от ALex_hha (ok) on 26-Сен-16, 19:06 
> Данное обновление безопасности исправляет проблемы, вызванные патчами, включёнными в наше предыдущее обновление безопасности.

ну классика - "В релизе X было исправленно Y ошибок". Просто о том, сколько при этом было внесено новых обычно умалчивают ;)

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

14. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Michael Shigorin email(ok) on 26-Сен-16, 19:24 
>> В RHEL/CentOS, Fedora и SUSE проблема не проявляется.
> Кто там в соседней теме про "ха-ха" писал? ;)

Да тут и https://www.opennet.ru/openforum/vsluhforumID3/109194.html#3 спрашивали...

PS: а двойная ирония ситуации да, великолепна :)

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

15. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от Аноним (??) on 26-Сен-16, 19:42 
Он даже в джаве теоретик, что перед ним бисер метать.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

18. "Критическая уязвимость в  OpenSSL 1.1.0a"  –3 +/
Сообщение от Аноним (??) on 26-Сен-16, 21:14 
Если не будет постоянных багов - программисты останутся без работы. Это как с полицией: если однажды преступность будет полностью побеждена, все полицейские будут уволены за ненадобностью. Си - это программистский хлеб в плане багообразования.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

20. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 26-Сен-16, 21:26 
Нужен еще один аудит, а потом заставить всех опеннетчиков читать код (или делать вид). Так победим.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Критическая уязвимость в  OpenSSL 1.1.0a"  –2 +/
Сообщение от KonstantinB (ok) on 26-Сен-16, 21:38 
Управляемый язык подразумевает виртуальную машину. Вот есть Java SSL, например, и что с этим делать вне JRE-мира?
Ответить | Правка | Наверх | Cообщить модератору

23. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от anonymous (??) on 26-Сен-16, 21:40 
C++ не является управляемым языком, однако ссылки там есть, вывод - надо писать на плюсах. А то на сишечке такой код нормально компилится и ждет своего часа.

    char a[256];
    char *buf = a;
    recv(hSocket, &buf, 256);

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

24. "Критическая уязвимость в  OpenSSL 1.1.0a"  +3 +/
Сообщение от KonstantinB (ok) on 26-Сен-16, 21:46 
Вы так говорите, как будто в C++ нельзя сделать dangling reference.

Есть, конечно, smart pointers, но это решает проблемы только локально и не всегда.

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

25. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от KonstantinB (ok) on 26-Сен-16, 21:48 
Аноним - не читатель, аноним - писатель. :-)
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

26. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от KM on 26-Сен-16, 22:28 
> PS: а двойная ирония ситуации да, великолепна :)

Ну а куда без неё? :)

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

27. "Критическая уязвимость в  OpenSSL 1.1.0a"  +3 +/
Сообщение от КО on 26-Сен-16, 22:51 
Потому, что ссылка, указатель и адрес в памяти есть тождественные синонимы одного и того же. Ваш КЭП. :)

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

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

28. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от scor (ok) on 26-Сен-16, 23:21 
> все полицейские будут уволены за ненадобностью

Вы так говорите, будто это что-то плохое.:)

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

29. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 26-Сен-16, 23:31 
Буратино тоже использует OpenSSL?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 26-Сен-16, 23:43 
> Буратино тоже использует OpenSSL?

Интересно, с чего вдруг такое предположение, если ББ сидит на OpenBSD, где LibreSSL по определению в базе?

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

32. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 27-Сен-16, 00:01 
Потому что ссылки это C++, а тупoрылые ретрограды которые пишут OpenSSL, и, кстати, большую часть FreeBSD, до сих пор используют plain C - устаревший, небезопасный и кoрявый язычoк.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

34. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 00:04 
Rust?
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

37. "Критическая уязвимость в  OpenSSL 1.1.0a"  +4 +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 00:11 
> Потому что ссылки это C++, а тупoрылые ретрограды которые пишут OpenSSL

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

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

Эх.

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

40. "Критическая уязвимость в  OpenSSL 1.1.0a"  –6 +/
Сообщение от iZEN email(ok) on 27-Сен-16, 00:46 
> Потому что в критически важных программах (особенно в криптографии) критически важна скорость и низкое потребление памяти.

Но в Go как-то решили обе эти проблемы. Или нет?
http://golang-book.ru/chapter-08-pointers.html


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

42. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от бедный буратино (ok) on 27-Сен-16, 01:22 
уже выпустили, за примерное поведение

сва-бо-ду бу-ра-ти-нам!

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

43. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Sw00p aka Jerom on 27-Сен-16, 01:34 
да куеватуча бест практис по секурному кодингу на сях, видать никто не читает, практики статического анализа у сишников нет, есть тока мантра дбг корки и всё, бага - да фиг с ней, корку под дбг и всё решено.

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

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

44. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Sw00p aka Jerom on 27-Сен-16, 01:36 
> Если не будет постоянных багов - программисты останутся без работы. Это как
> с полицией: если однажды преступность будет полностью побеждена, все полицейские будут
> уволены за ненадобностью. Си - это программистский хлеб в плане багообразования.

ага и касперский пишет вирусы )))

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

45. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Sw00p aka Jerom on 27-Сен-16, 01:38 
> Еще один факт, доказывающий что в OpenSSL некомпетентные люди пилят.
> Вообще OpenSSL через разные утилиты прогонят и проверяют через профайлеры?
> Мое предпочтение ИМХО LibreSSL и был бы рад когда FreeBSD перейдет на
> него по умолчанию как сделали это DragonFlyBSD.

с ситемой то будет поставляться либра, а вот половина софта из портов (пакетов) юзают именно openssl, не отвяжешся так просто.

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

46. "Критическая уязвимость в  OpenSSL 1.1.0a"  +3 +/
Сообщение от angra (ok) on 27-Сен-16, 02:32 
> Если не будет постоянных багов - программисты останутся без работы.

Создавать новые программы для тебя не вариант? Предпочитаешь паразитировать на исправлении и добавлении багов в одну и ту же?

> Это как с полицией: если однажды преступность будет полностью побеждена, все полицейские будут уволены за ненадобностью.

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

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

47. "Критическая уязвимость в  OpenSSL 1.1.0a"  +3 +/
Сообщение от KonstantinB (ok) on 27-Сен-16, 02:34 
Разве что теоретически - если вообще всё на нем вообще переписать, не используя unsafe-функции и raw pointers. На практике малореализуемо.

Вот что на практике реализуемо - так это использовать инструменты статического и динамического анализа и придерживаться единого стиля. Большинство проблем с openssl - следствие исторически сложившейся запутанности его кода и отсутствия этих самых best practices: когда ответственность за выделение/освобождение памяти разнесена как попало, подобные ошибки просто неизбежны. Форки типа libressl как раз это и пытаются решить.

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

49. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от angra (ok) on 27-Сен-16, 02:37 
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

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

50. "Критическая уязвимость в  OpenSSL 1.1.0a"  –6 +/
Сообщение от Сторонник прогресса on 27-Сен-16, 02:50 
> Создавать новые программы для тебя не вариант?

Для меня - вполне себе вариант. Я говорил о сишниках и об их деятельности по многодесятилетнему созданию и исправлению одних и тех же багов. Топчутся на одном месте, зато зарплата идет. И видимость работы как бы есть. Вон, сколько багов закрыли. Ух! А потом закроют еще больше, внося каждый раз два новых бага на место одного закрытого.

> Ты, когда дождик кончается, зонтик сразу выкидываешь за ненадобностью?

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

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

51. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Led (ok) on 27-Сен-16, 03:00 
> http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.

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

52. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Led (ok) on 27-Сен-16, 03:01 
> Да, я увольняю зонт, запихивая его с глаз долой куда подальше.

Как для маковода - вполне предсказуемые действия.

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

53. "Критическая уязвимость в  OpenSSL 1.1.0a"  +5 +/
Сообщение от Какаянахренразница (ok) on 27-Сен-16, 03:06 
> Потому что C - это религия.

Никогда не считал себя религиозным фанатиком, но ты мне не нравишься. [ушёл собирать хворост для костра]

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

54. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от kachsheev (ok) on 27-Сен-16, 03:25 
Void Linux как раз на либре. :)
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

56. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от eRIC (ok) on 27-Сен-16, 07:01 
> с ситемой то будет поставляться либра, а вот половина софта из портов
> (пакетов) юзают именно openssl, не отвяжешся так просто.

согласен, но со временем и софт с портов начнет внедрять поддержку LibreSSL...

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

57. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от бедный буратино (ok) on 27-Сен-16, 07:05 
половина? в OpenBSD я недавно насчитал 6 штук. или 5. причём половина из них - из-за неторопливости маинтайнеров, как мне кажется
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

58. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 08:19 
Снова, опять.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

59. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 09:53 
Так зачем писать фигню, а потом её компилить и релизить?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

60. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от curious on 27-Сен-16, 10:23 
> Я говорил о сишниках и об их деятельности по многодесятилетнему созданию и исправлению одних и тех же багов.
> Топчутся на одном месте, зато зарплата идет. И видимость работы как бы есть.

То ли дело Java программисты.
Только вперёд! Если класс, то только с новой функциональностью!
Без всякой зарплаты! За идею!

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

61. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 10:23 
Хороший результат у Go. Даже в таком виде...
Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

62. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Andrey Mitrofanov on 27-Сен-16, 10:39 
> Аноним - не читатель, аноним - писатель. :-)

Пусть эти, как их... зарегистрированные читют.

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

63. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от труляляй on 27-Сен-16, 10:46 
есть еще копипейст и очепятки, причём во всех языках.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

64. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от angra (ok) on 27-Сен-16, 10:47 
То есть с точки зрения эльфа баги есть только в Сишных программах. На php, где нет богомерзких указателей, пишут исключительно безбажные программы?

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

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

65. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от angra (ok) on 27-Сен-16, 10:49 
Хороший, не спорю, но Изя то говорил про полное решение проблем с производительностью и памятью, не иначе как с помощью магии. На деле же видим типичный tradeoff и никакого волшебства.
Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

66. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Клыкастый (ok) on 27-Сен-16, 11:28 
D?
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

67. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от невидимка on 27-Сен-16, 11:45 
>  тупoрылые ретрограды

А уж генетический код то какой устаревший.... Все эти ДНК,РНК и т.д. УЖАСТЬ КАКОЕ СТАРЬЁ!

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

68. "Критическая уязвимость в  OpenSSL 1.1.0a"  –2 +/
Сообщение от Аноним (??) on 27-Сен-16, 11:58 
> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.

Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда и проверок не будет :)

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

69. "Критическая уязвимость в  OpenSSL 1.1.0a"  –5 +/
Сообщение от Аноним (??) on 27-Сен-16, 12:00 
> На php, где нет богомерзких указателей, пишут исключительно безбажные программы?

На пыхе баги в основном касаются бизнес-логики. А на сишечке -- бизнес-логика + стандартные вечные stack overflow. Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс. Сишники же просто в лоб решают свою хроническую болезнь и не собираются отказываться от ручного управления памятью. Ну тут уж можно сказать только одно: каждый доказывает свою нужность так, как может. Сишники например - путем постоянной генерации и исправления однотипных багов.

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

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

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

70. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 12:23 
>> На php, где нет богомерзких указателей, пишут исключительно безбажные программы?
> На пыхе баги в основном касаются бизнес-логики.

И много sql injections или csrf бывает в бузинес-логике всяких joomla с phpmyadmin?

> А на сишечке -- бизнес-логика + стандартные вечные stack overflow.

И много Вы лично видали именно bl на Це?

> Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько
> случались sql-инъекции. Что сделали пыхеры? Стали обращаться к бд посредством
> безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс.

Что, серьёзно уничтожили?

Сдаётся мне, у Вас просто какая-то идея фикс насчёт геноцида, при этом причину ошибок понять не в состоянии -- возможно, по той простой причине, что свои собственные ошибки анализировать не склонны, как и персонажи http://egorfine.com/ru/articles/worse-than-failure/

> Сишники же просто в лоб решают свою хроническую болезнь и не собираются отказываться
> от ручного управления памятью.

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

> Ну тут уж можно сказать только одно: каждый доказывает свою нужность так, как может.

Отлично иллюстрируете своё утверждение.

> Сишники например - путем постоянной генерации и исправления однотипных багов.

Не то что php-шники? (среди которых профи есть, но за теми подобных высказываний не припоминаю)

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

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

Вас если выгнать -- за дело или просто так -- в следующий раз в ту же лавку будете рваться с удвоенной силой?  Не, серьёзно?

А если так поразгонять дворников, то листья перестанут падать?..

PS: буду крайне рад ошибиться в оценочных суждениях, разумеется.

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

71. "Критическая уязвимость в  OpenSSL 1.1.0a"  –3 +/
Сообщение от Аноним (??) on 27-Сен-16, 13:18 
> при этом причину ошибок понять не в состоянии

Причина ошибок что с sql-инъекциями, что со stack overflow, одна и та же: невнимательность. Только пыхеры признали невнимательность как свою проблему и одолели ее. А сишники продолжают считать себя сверх-людьми, умеющими вовремя распознавать ситуации, когда требуется освободить память. Не зря в библии гордыня считается одним из смертных грехов. (И нет, я не религиозник.)

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

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

> если так поразгонять дворников, то листья перестанут падать?

Если однажды случится такое, что листья принципиально перестанут падать, то сборщиков листьев придется уволить. Ты здесь слегка попутал причину и следствие.

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

72. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 13:33 
>> при этом причину ошибок понять не в состоянии
> Причина ошибок что с sql-инъекциями, что со stack overflow,
> одна и та же: невнимательность.

Ура!

> Только пыхеры признали невнимательность как свою проблему и одолели ее.

Ну вот, опять сказки пошли...

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

Да-да, неломающиеся и неглючащие роботы, которые берутся из ниоткуда и деваются в никуда.  Языки программирования, где достаточно нажать Кнопку.  И всё такое прочее.

>> если так поразгонять дворников, то листья перестанут падать?
> Если однажды случится такое, что листья принципиально перестанут падать,
> то сборщиков листьев придется уволить. Ты здесь слегка попутал причину и следствие.

Я намеренно "запряг телегу впереди лошади" в вопросе о том, может ли преступность пропасть как класс (sic!) в зависимости от эффективности противодействия таковой.  Ну, вдруг заметите, где у Вас этсамая путаница причин, следствий и отсутствия таковых.

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

73. "Критическая уязвимость в  OpenSSL 1.1.0a"  –3 +/
Сообщение от Аноним (??) on 27-Сен-16, 13:48 
> Ну вот, опять сказки пошли...

Повсеместное использование query-build-еров и подстановок - сказка? Отнюдь. Пыхеры просто сделали так, чтобы их невнимательность больше не угрожала безопасности. Сишники не идут их путем по причинам, которые я изложил выше.

> неломающиеся и неглючащие роботы

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

> может ли преступность пропасть как класс (sic!) в зависимости от эффективности противодействия таковой

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

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

74. "Критическая уязвимость в  OpenSSL 1.1.0a"  +2 +/
Сообщение от Аноним84701 on 27-Сен-16, 13:55 
> в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали
> обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон.

Слишком жЫрно.
Те же prepared statements появились в *рен-знает-каком году.
В пыхе встроенная поддержка как минимум  с 2006 года ... но пыховцы о ней слышали:
https://www.cvedetails.com/vulnerability-list/opsqli-1/sql-i...
> Total number of vulnerabilities : 6362

что-то хвалененая обучаемость не спешит проявлятся )

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

75. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 13:58 
>> Ну вот, опять сказки пошли...
> Повсеместное использование query-build-еров и подстановок - сказка? Отнюдь.

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

>> неломающиеся и неглючащие роботы
> Если робот поломался - то поломался он для всех сразу.

Как правило, всего лишь для пользователей экземпляра.

> Следовательно, если пофиксить робота - пофиксятся сразу все баги сразу у всех
> клиентов робота.

Зависит от конкретики "пофиксить" и "все баги" как минимум.  Доводилось видать людей, необузданный оптимизм которых в подобных формулировках приводил к большим проблемам...

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

>> может ли преступность пропасть как класс (sic!) в зависимости
>> от эффективности противодействия таковой
> Разумеется может.

Хотя бы один известный практический пример воспоследует?

> Гораздо более эффективными явили себя частные страховые агенства.

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

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

Часом не утопий обчитались?

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

76. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним84701 on 27-Сен-16, 14:31 
>> Результат предсказуем прежде всего из-за слабенького (по сравнению с GCC) оптимизатора в Go.
> Если ты оптимизируешь проверки границ массивов - тормозить, конечно, перестанет, но тогда
> и проверок не будет :)

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


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

77. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от мда on 27-Сен-16, 14:31 
К чему это или о чем?
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

78. "Критическая уязвимость в  OpenSSL 1.1.0a"  +4 +/
Сообщение от Аноним (??) on 27-Сен-16, 15:10 
Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество мест за которыми нужно следить сокращается многократно.

Но всё же это всё мечты – переносить проект после такого длинного пути развития на plain c даже на плюсы уже целая эпопея (см. gcc).

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

79. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 27-Сен-16, 15:21 
> Конечно можно. Голод не тетка. Эффективность правда будет уже не той. Она будет повыше. Потому что полицейские теперь будут знать, что раз их уже увольняли - в этот раз им понадобится доказывать свою нужность с удвоенной силой. И тогда совершенно точно можно не ожидать исстребления преступности как класса.

Они уже умные и заранее работают с ДОСТАТОЧНОЙ эффективностью. Работа как видите у них не кончается и увольнять никого не нужно

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

80. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 15:23 
> Настолько категорично переписывать всё и не обязательно – даже с unsafe-ом количество
> мест за которыми нужно следить сокращается многократно.
> Но всё же это всё мечты – переносить проект после такого длинного
> пути развития на plain c даже на плюсы уже целая эпопея
> (см. gcc).

Многие проекты на C переносятся на плюсы переименованием файлов в .cpp, и добавлением префикса extern "C" для функций API

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

81. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 15:27 
> Они уже умные и заранее работают с ДОСТАТОЧНОЙ эффективностью.
> Работа как видите у них не кончается и увольнять никого не нужно

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

Ну и листья всё так же падают...

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

82. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от аноним2 on 27-Сен-16, 15:28 
> да куеватуча бест практис по секурному кодингу на сях, видать никто не читает

А можно ссылочку?

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

83. "Критическая уязвимость в  OpenSSL 1.1.0a"  +3 +/
Сообщение от Аноним (??) on 27-Сен-16, 15:39 
Может всё же не стоит путать пренос кода на другой язык с подключением этого же кода к коду на другом языке?
Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

84. "Критическая уязвимость в  OpenSSL 1.1.0a"  –2 +/
Сообщение от Аноним (??) on 27-Сен-16, 15:49 
В моём районе есть кирпич и водители постоянно под него едут, и полицейские приезжают и штрафуют с достаточной периодичностью чтобы водители не слишком боялись. Можно было бы повесить камеру и начислять штрафы автоматом, но тогда поток нарушений закончился бы и камера была бы не нужна. И так не только в моём примере.

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

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

85. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 27-Сен-16, 16:28 
Станислав Лем. Звездные дневники Ийона Тихого. Путешествие двадцать четвертое
Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

86. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 27-Сен-16, 17:01 
> Может всё же не стоит путать пренос кода на другой язык с
> подключением этого же кода к коду на другом языке?

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

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

87. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Аноним (??) on 27-Сен-16, 17:06 
Его главная проблема в том, что он метит скорее к высокоуровенным языкам, и в плане безопасности от тех же плюсов без использования GC не ушёл никуда.
Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

88. "Критическая уязвимость в  OpenSSL 1.1.0a"  –2 +/
Сообщение от Клыкастый (ok) on 27-Сен-16, 17:40 
> Его главная проблема в том, что он метит скорее к высокоуровенным языкам,

высокоуровневые это C? он от сишника недалеко ушёл, и вынос некоторых вещей на уровень стиля программирования и проверку части ошибок на компилятор не сильно его приближает к жабам и окамлам. ИМХО то, что заказывали: "низкоуровневое" как C, чуть более безопасное, как C++. Это просто мои соображения, категорично утверждать не буду.

> и в плане безопасности от тех же плюсов без использования GC не ушёл никуда.

насколько я знаю использует подсчёт ссылок. уже хорошо.

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

89. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 17:53 
> Можно было бы повесить камеру и начислять штрафы автоматом, но
> тогда поток нарушений закончился бы и камера была бы не нужна.

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

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

В целом да.

> Программируя на Си не ошибаться невозможно

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

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

90. "Критическая уязвимость в  OpenSSL 1.1.0a"  –2 +/
Сообщение от _ (??) on 27-Сен-16, 18:11 
Теперь D принято писать так:
:-D

Потому что не взлетели.

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

92. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Аноним (??) on 27-Сен-16, 18:26 
>насколько я знаю использует подсчёт ссылок. уже хорошо.

Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной библиотеке как и в плюсах (при этом самое смешное что использовать их с отлкюченным GC или без рантайма не получится - эта реализация взаимодействует со сборщиком, чтобы тот корректно работал).
>высокоуровневые это C? он от сишника недалеко ушёл

Вот вообще ни разу - без сборщика течёт половина языка (те же билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом языке нет - есть в стандартной библиотекие, которая без GC не работает :)  

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

93. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Michael Shigorin email(ok) on 27-Сен-16, 20:06 
>> если бы люди стали безгрешными, причём все
> Станислав Лем. Звездные дневники Ийона Тихого. Путешествие двадцать четвертое

Там не люди (что до, что после "гармонизации").

PS: но всяко спасибо :)

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

94. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Sw00p aka Jerom on 27-Сен-16, 21:21 
Гугл  помощь, или  примеру на cert.org посмотри, там есть книжка по secure coding
Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

97. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от angra (ok) on 27-Сен-16, 23:38 
Нет, не гладиолус, а по причине того, что проверка выполняется при каждой операции, так что абсолютно фиолетово какой там размер массива.
Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

98. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от angra (ok) on 27-Сен-16, 23:58 
> Пыхеры проявляют гораздо бОльшую обучаемость, чем сишники; например, в пыхе частенько случались sql-инъекции. Что сделали пыхеры? Стали  обращаться к бд посредством безопасных query-builder-ов или подставляя значения в шаблон. Уничтожили баги как класс.

Спасибо, посмеялся. Обучаемость основной массы пыхеров это просто пять с плюсом, особенно с учетом "подставляя значения в шаблон", ведь именно так и получаются sql инъекции. Ты бы хоть про prepared statement почитал, которые есть в пыхе уже с десяток лет, но инъекции никуда не деваются, так как особо одаренные все еще подставляют значения в шаблон.  


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

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


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

99. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним84701 on 28-Сен-16, 00:47 
> Нет, не гладиолус, а по причине того, что проверка выполняется при каждой
> операции, так что абсолютно фиолетово какой там размер массива.

При последовательном обходе, копировании в/из и т.д:
mprotect(..., PROT_NONE) на страничку памяти (или несколько, зависит от размера элементов) после массива — и ваши массивы будут мягкими и шелковистыми! Да и проверка (одна) в таком случае нужна только перед началом сего действа  и только в том случае, если собираемся проходить не с нулевого элемента.

Просто "стOит" это дело одну-две дополнительные страницы памяти (т.к. "валидная" длина массива будет кратной размеру страницы памяти), и не спасет при произвольном доступе/заполнении.

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

100. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от angra (ok) on 28-Сен-16, 02:15 
Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается или пишется один элемент. Даже если это делается в цикле, проходящем по всем элементам, то это ничего не меняет, проверка нужна на каждое обращение. Этого можно избежать в языках с конструкциями each/foreach, которые избавляют от явного индексирования, но в С их нет.

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

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

102. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Аноним (??) on 28-Сен-16, 11:02 
> Как же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие восхваляемый инструмент в руки и не показывающие, как было надо сделать сразу.

Так я на C++ пишу. И что-то дырок в моих проектах каждый день по десятку не находят.

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

Глупый ты, миша.

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

103. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 28-Сен-16, 11:41 
>> Как же всё-таки безнадёжно выглядят вот такие организмы, почему-то не берущие
>> восхваляемый инструмент в руки и не показывающие, как было надо сделать сразу.
> Так я на C++ пишу. И что-то дырок в моих проектах каждый день по десятку не находят.

Джо, но где же Ваша реализация SSL-библиотеки?

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

Может быть.  Только что-то уже повидавший.  В том числе и такое.

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

104. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от Клыкастый (ok) on 28-Сен-16, 12:11 
> Нет, не использует. Ну, точнее есть самая наивная реализация самртпоинтеров в стандартной
> библиотеке как и в плюсах (при этом самое смешное что использовать
> их с отлкюченным GC или без рантайма не получится - эта
> реализация взаимодействует со сборщиком, чтобы тот корректно работал).

по хабрам и D-пабликам ходит статья про обёртки для работы с отключеным GC, не оно? (про ровность такого решения пока не будем).

> Вот вообще ни разу - без сборщика течёт половина языка (те же
> билтиновые массивы, строки, замыкания и тд), аллокации на стёке в самом
> языке нет - есть в стандартной библиотекие, которая без GC не
> работает :)

всё так плохо?

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

105. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним84701 on 28-Сен-16, 14:33 
> Массивы чаще всего используются так 'a[i]' или так 'a[i]=...', то есть читается
> или пишется один элемент. Даже если это делается в цикле, проходящем
> по всем элементам, то это ничего не меняет, проверка нужна на
> каждое обращение.

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

> Этого можно избежать в языках с конструкциями each/foreach, которые
> избавляют от явного индексирования, но в С их нет.

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

> mprotect это очень тяжелая операция,

Никто не говорил, что mprotect так уж "легок", но
strace ls
strace time
Вполне себе применяется для "разметки" границ стека или кучи.

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

106. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Andrey Mitrofanov on 28-Сен-16, 14:53 
> Фак.
> Ну сколько можно так косячить...

В следующих сериях нашего сериальчика Вы также увидите рассказы клоунов нашего секьюрить сыркуса про то, что так было и так будет есть. Также приглашённая звезда развенчает весь сыркус и сделает пару победных кругов по манежу. Следите за анонсами!
https://outflux.net/slides/2016/lss/kspp.pdf
http://kernsec.org/files/lss2015/giant-bags-of-mostly-water.pdf

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

107. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от angra (ok) on 29-Сен-16, 01:34 
for (i=0;i<n;i++) {
if (smth) {
   i=m
}
a[i]=a[i-1]+a[i-2]
b[i]=f(a[i])
}

Вот тебе всего три из множества возможных вариантов, в которых твой наивный подход не работает.

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

108. "Критическая уязвимость в  OpenSSL 1.1.0a"  +1 +/
Сообщение от Аноним84701 on 29-Сен-16, 03:35 
>  if (smth) {
>    i=m
>  }
> Вот тебе всего три из множества возможных вариантов, в которых твой наивный
> подход не работает.

Ну-ну.

1. То, что вариант с smth != true => a[-1] + a[-2] => fail
можно, совершенно внезапно, ловить еще на этапе компиляции.
2. m в реальном коде берется не из либастрала и вполне прослеживается компилятором — как минимум возможные значения (для всяких разных constant propagation, partial evaluation и всего такого).
3.  см.
>> если не заниматься  извращениями
>

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

109. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 29-Сен-16, 04:31 
> ага и касперский не пишет вирусы )))

fix

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

110. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 29-Сен-16, 08:45 
> То ли дело Java программисты.
> Только вперёд! Если класс, то NullPointerException
> Без всякой зарплаты! За идею!

Не удержался.

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

111. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 29-Сен-16, 08:47 
> stack overflow

Может случиться в любой программе на любом языке, от незнания\криворукости\усталости программера. Просто в C++\Java она выкинет эксепшн, только и всего.

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

112. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от anonymous (??) on 29-Сен-16, 09:35 
Бред. ""_ptr's (и smart_ptr) не имеют к GC никакого отношения. Все сводится к подсчету ссылок (ну, и определённые гарантии по жизненному циклу объектов).
Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

113. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 29-Сен-16, 11:08 
Может стоит сначала открыть исходники и посмотреть прежде чем писать?
Или объяснить принцип работы GC и как память выделенная внутри объекта завёрнутого в смартпоинтер отслеживается сборщиком?
Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

114. "Критическая уязвимость в  OpenSSL 1.1.0a"  –1 +/
Сообщение от yaa on 29-Сен-16, 11:23 
> Может стоит сначала открыть исходники и посмотреть прежде чем писать?

Именно так. Вам стоит таки открыть исходники.

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

115. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Аноним (??) on 29-Сен-16, 16:26 
https://github.com/dlang/phobos/blob/master/std/typecons.d#L...
Ну...
Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

116. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от yaa on 29-Сен-16, 19:46 
А, так речь про D... Тогда все эти комментарии надо потереть.
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

117. "Критическая уязвимость в  OpenSSL 1.1.0a"  +/
Сообщение от Michael Shigorin email(ok) on 29-Сен-16, 19:55 
> А, так речь про D... Тогда все эти комментарии надо потереть.

Если какие-либо Ваши потеряли смысл после уточнения -- приведите их номера, пожалуйста.

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


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

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




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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