| |
| 2.3, Аноним (-), 22:12, 03/05/2016 [^] [^^] [^^^] [ответить]
| +8 +/– |
ты небось и купаться ходишь раз в год в четверг перед пасхой?
| | |
| 2.10, Анончег (?), 22:39, 03/05/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Несмотря на то, что проблема актуальна только для старых необновлённых версий, она затрагивает и пакеты в дистрибутивах, основанных на старых выпусках OpenSSL. В том числе уязвимости подвержены пакеты с openssl в Debian...
надо же, кто бы мог предположить, что как раз Дебиян?
| | |
| |
| 3.14, Аноним (-), 01:51, 04/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Несмотря на то, что проблема актуальна только для старых необновлённых версий, она затрагивает и пакеты в дистрибутивах, основанных на старых выпусках OpenSSL. В том числе уязвимости подвержены пакеты с openssl в Debian...
> надо же, кто бы мог предположить, что как раз Дебиян?
Сарказм - самая примитивная форма юмора. Итого, критика есть, как на счёт предложений?
| | |
|
|
| 1.9, Ilya Indigo (ok), 22:36, 03/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Ждём прилёта openssl-1.0.2h в зелёнке, а также пересобранных apache2, php5, php7 и конечно же openssh-6.6p1
| | |
| |
| 2.12, Аноним (-), 23:18, 03/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Ждём прилёта openssl-1.0.2h в зелёнке, а также пересобранных apache2, php5, php7 и
> конечно же openssh-6.6p1
А зачем их пересобирать? Или разделяемые библиотеки уже не в моде?
| | |
| |
| 3.15, Аноним (-), 01:59, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
>> Ждём прилёта openssl-1.0.2h в зелёнке, а также пересобранных apache2, php5, php7 и
>> конечно же openssh-6.6p1
> А зачем их пересобирать? Или разделяемые библиотеки уже не в моде?
Безотносительно ОС и дистрибутивов.
Так библиотеки зачастую разделяемые между сторонними приложениями а не внутри минорной версии самой библиотеки. Одни делают симлинки на новую версию библиотеки вручную или доверяют эту операцию дистрибутиву, другие чтобы обновляют всё, чтобы не было распорок.
Про специфичный софт проверяющий версии/контрольные суммы библиотек молчу.
| | |
| |
| 4.16, Аноним (-), 02:05, 04/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>> Ждём прилёта openssl-1.0.2h в зелёнке, а также пересобранных apache2, php5, php7 и
>>> конечно же openssh-6.6p1
>> А зачем их пересобирать? Или разделяемые библиотеки уже не в моде?
> Безотносительно ОС и дистрибутивов.
> Так библиотеки зачастую разделяемые между сторонними приложениями а не внутри минорной
> версии самой библиотеки. Одни делают симлинки на новую версию библиотеки вручную
> или доверяют эту операцию дистрибутиву, другие чтобы обновляют всё, чтобы не
> было распорок.
Блин. Я и забыл про маразм с симлинками (в Опёнке их нет). :( Молчу, молчу.
> Про специфичный софт проверяющий версии/контрольные суммы библиотек молчу.
o_O Я такое встречал в ОЧЕНЬ специфическом, сертифицируемом софте. Ну так туда и новые версии ничего не попадут. Потому что сертификацию повторно никто проходить не будет... Ещё такое может быть при использовании какого-нибудь монитора хакерской активности, но тут уж извините, откровенно ложноположительное срабатывание получается... Честное слово, не понимаю. Про какой специфичный софт вы говорите?
| | |
|
|
|
| 1.17, бедный буратино (ok), 05:28, 04/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 два дня вялотекущим образом собирал образы -stable для i386 и amd64... и вот.
да ну вас! нет никаких уязвимостей, враки это всё! не буду ничего пересобирать.
| | |
| 1.19, Вареник (?), 06:25, 04/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Самый важный компонент сетевой безопасности - самый дырявый...
Все в соответствии с Мерфи и Паркинсоном.
| | |
| |
| 2.21, Аноним (-), 07:58, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Самый важный компонент сетевой безопасности - самый дырявый...
А король то голый! Не с проста последние годы очень активно навязывают переход всех на HTTPS. Типа приватность, слежка спецслужб и прочая муть, а то что в подвале все трубы давно сгнили забывают. Лет 15 назад HTTPS не ставили не потому, что было плевать на данные пользователей, а из-за того, что mod_ssl был дыряв и крив до безобразия. С nginx ситуация немного улучшилась, но openssl и gnutls хламом и остались.
| | |
|
| 1.20, Аноним (20), 07:51, 04/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Опять повреждение памяти и выход за границы массива. Пора уже взять за правило писать криптографию только на управляемых языках. Медленно, зато огромный пласт ошибок и уязвимостей исчезнет как класс. Но нет, будет продолжать жрать кактус. В общем ССЗБ.
| | |
| |
| 2.24, Аноним (-), 11:35, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
клоун: Специально для тебя объясняю: проблемы с памятью является неизбежными, независимо от используемого ЯП. Если ЯП абстрагирует управление памятью, значит проблема спускается на уровень ниже, и теперь будет не в самом ПО, а в компиляторе/интерпритаторе. Попытка решить все проблемы выбрав "правильный" ЯП обречена на провал.
| | |
| |
| 3.25, Аноним (20), 13:09, 04/05/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Неа. В это случае уменьшается количество точек отказа. Сравни: исправление ошибки в коде одного компилятора и исправление ошибки в коде тысяч проектов.
| | |
| 3.27, Аноним (-), 13:59, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> клоун: Специально для тебя объясняю: проблемы с памятью является неизбежными, независимо
> от используемого ЯП.
Надеюсь, хоть с умным видом писалось?
> Если ЯП абстрагирует управление памятью, значит проблема спускается
> на уровень ниже, и теперь будет не в самом ПО, а
> в компиляторе/интерпритаторе.
Ну да, у GC и куча всяких проверок в рантайме, отсутствием которых так гордятся Ъ-язычнеги, совсем ничего не дают. Это же все знают! Поэтому сравнение/циферки подтверждающие сию умную мыслю мы никогда не увидим.
| | |
| |
| 4.30, Аноним (-), 15:29, 04/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
клоун: Типичные ошибки по работе с памятью в ЯП, который сам управляет памятью.
Обращение за границу массива. Данные записываются не просто так, а с определённой целью. Если они не будут записаны, это вызовет логическую ошибку в другом месте кода.
Обращение к освобождённой или невыделенной памяти. Обращение на чтение к неинициализированным данным приведёт к логической ошибке в другом месте кода.
Запись/чтение в чужой буфер. Ошибку в написании имени переменной ЯП не отследит, а запись в чужой буфер приведёт к логической ошибке в другом месте кода.
Итог: мы заменили ошибку в месте её возникновения на ошибку, которая возникнет, но позже. Зачем?
Пока переменные хранятся в памяти, этой памятью нужно будет управлять.
| | |
| |
| 5.32, Аноним (-), 16:02, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> клоун: Типичные ошибки по работе с памятью в ЯП, который сам управляет
> памятью.
Это в какой вселенной они типичные?
> Обращение за границу массива. Данные записываются не просто так, а с определённой
> целью. Если они не будут записаны, это вызовет логическую ошибку в
> другом месте кода.
А ошибка при записи данных будет проигнорирована, потому что гладиолус? По этой же причине язык с авто-GC не будет ничего делать с границами массива – пользовоатель ЯП с ГЦ должен заниматься всем этим вручную, потому как языки с ГЦ для лохов и никаких преимуществ у них нет, только недостатки!
> Обращение к освобождённой или невыделенной памяти.
> Обращение на чтение к неинициализированным данным
> приведёт к логической ошибке в другом месте кода.
Во-первых, предупреждения еще никто не отменял.
Во-вторых, в некоторых ЯП это еще надо умудриться сделать.
В-третьих, найти обращение к неинициализированным переменным для всяких линтов намного проще, чем обращения к освобожденной памяти в языках с ручным управлением.
> Запись/чтение в чужой буфер. Ошибку в написании имени переменной ЯП не отследит,
> а запись в чужой буфер приведёт к логической ошибке в другом
> месте кода.
Гм, и каким боком тут управление памяти?
> Итог: мы заменили ошибку в месте её возникновения на ошибку, которая возникнет,
> но позже. Зачем?
Напоминает очередное "это не баг в моем 'привете миру', это баг в гцц!"
> Пока переменные хранятся в памяти, этой памятью нужно будет управлять.
И вы гордо, вручную освобождаете стек и регистры!
| | |
| |
| 6.33, Аноним (-), 16:30, 04/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
клоун: ЯП, управляющий памятью должен обработать последовательность команд:
1. создать массив из 10 элементов
2. присвоить 11-ому элементу массива значение N
Вариантов немного:
1. он проигнорирует вторую команду, чем вызовет логическую ошибку позднее
2. выполнение 2-ой команды приведёт к исключению, в таком случае его поведение немногим отличается от ситуации в существующих ЯП
3. он выполнит 2-ую команду, самопроизвольно (!) увеличив размер массива. Это сделает ЯП неуправляемым: создав массив размером 10 элементов, мы не можем быть уверены в его размере.
И речь я веду совсем не о сборщике мусора.
| | |
| |
| 7.36, Аноним (-), 16:55, 04/05/2016 [^] [^^] [^^^] [ответить]
| +/– |
> 2. выполнение 2-ой команды приведёт к исключению, в таком случае его поведение
> немногим отличается от ситуации в существующих ЯП
В параллельных вселенных и сферических юзкейзах вполне возможно.
Но обычно народ таки предпочитает нарваться сразу на исключение, чем на непонятный баг, где далеко не сразу определишь, откуда у него "ноги растут".
> 3. он выполнит 2-ую команду, самопроизвольно (!) увеличив размер массива.
Да, это так внезапно для языка с автоматическим управлением памятью!
> Это сделает ЯП неуправляемым:
Кэп, залогинтесь!
> создав массив размером 10 элементов, мы не можем быть
> уверены в его размере.
И чем это плохо?
Во-первых, создайте массив на 10 элементов в плейн-си, сделайте gcc -S -O2 и удивитесь размерам.
Во-вторых, чем вы опять собрались там "управлять" и "рулить"?
Вы уж определитесь – вам шашечки в виде создания массива на 10 элементов и последующего рулежа оным …
Или все же ехать – хранить элементы, (которых может оказаться 11 вместо десяти).
Обычно таки
| | |
| |
| 8.37, Аноним (-), 17:00, 04/05/2016 [^] [^^] [^^^] [ответить] | +/– | Обычно таки народу нужно хранить элементы Причем, продвинутые даже вполне могут... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.22, robux (ok), 08:27, 04/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Что характерно, все дыры пасутся на высоком уровне: либо в SSL, либо в стандартизированных форматах хранения сертификатов.
Какой вывод напрашивается?
Используй низкоуровневые функции и не используй всякие мутные "стандарты"!
(Сначала проленятся, насуют себе полную ж-пу ISO-шных стандартов, а потом удивляются, что там сифонит).
| | |
| |
| 2.28, Аноним (-), 14:54, 04/05/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
Подскажите-ка "низкоуровневую" либу для шифрования, да такую, чтоб не сифонило, с открытым кодом и поддерживаемую всеми? Нема? Ну так идите лесом с вашими советами.
| | |
| |
| 3.29, Аноним (-), 15:18, 04/05/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Подскажите-ка "низкоуровневую" либу для шифрования, да такую, чтоб не сифонило, с открытым
> кодом и поддерживаемую всеми? Нема? Ну так идите лесом с вашими
> советами.
libsodium. не?
| | |
| 3.35, robux (ok), 16:48, 04/05/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Подскажите-ка "низкоуровневую" либу для шифрования
При чём здесь "низкоуровневая либа"?
Я сказал низкоуровневые функции!
А либа всё та же самая - OpenSSL (или LibreSSL, по вкусу).
| | |
|
|
| 1.34, КО (?), 16:43, 04/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>Уязвимость была внесена вместе с исправлением для блокирования атак
Змей поедающий свой хвост. :)
| | |
| 1.38, Аноним (-), 21:14, 05/05/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
> В том числе уязвимости подвержены пакеты с openssl в Debian, RHEL/CentOS/Fedora, Ubuntu и SUSE, в которые исправление не было перенесено, так как оно было квалифицировано как устранение ошибки, а не уязвимости.
Вся суть штабильной тухлятины и цирка с бэкпортированием из апстрима. JWZ был прав.
| | |
|
