Роберт Ли (Robert E. Lee), руководитель подразделения безопасности шведской компании Outpost24, сообщил, что он и его коллега Джек Луис (Jack Louis) обнаружили уязвимость еще в 2005, но решили придержать информацию в надежде обнаружить обходные пути. Однако, окончательно упершись лбом в стенку, они решили обнародовать эти сведения. В течение последнего месяца были проинформированы основные производители операционных систем, маршрутизаторов и межсетевых экранов. В настоящее время не существует реализации TCP-стека, свободного от данной уязвимости (проверено было 15 реализаций).

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

Источник: The Register

Tweet

теги: dos, уязвимости, retro  |  предложить новость  |  обсудить  |  все отзывы (21)

[7849]

назад «  » вперед

аналогичные материалы Опасная и все еще неисправленная восьмилетняя уязвимость в PHP // 04.05.12 17:27 Oracle срочно выпустила бюллетень, посвященный блокировке четырехлетней уязвимости // 01.05.12 21:12 Пятилетняя уязвимость в Samba // 11.04.12 22:12 DoS на SSL // 26.10.11 17:15 Взлом HTTPS: десятилетняя теоретическая уязвимость в SSL/TLS стала реальной // 26.09.11 23:46 Создатели Apache срочно бросились исправлять ошибку четырехлетней давности // 25.08.11 00:06 Бэкдор в QuickTime // 03.09.10 01:51

последние новостиBugTraq.Ru: последние новости Adobe все-таки выпустит бесплатные обновления для CS5.x // 14.05.12 11:13 CGI-уязвимость в PHP: второй подход к снаряду // 09.05.12 17:54 Adobe пропатчила Shockwave, Flash, Photoshop, Illustrator // 09.05.12 00:00 Майские обновления от MS // 08.05.12 21:21 Присяжные признали Google частично виновной в нарушении копирайта на Java API // 08.05.12 14:14 Февральское обновление Lion раскрыло пользовательские пароли // 06.05.12 20:51 Опасная и все еще неисправленная восьмилетняя уязвимость в PHP // 04.05.12 17:27

Комментарии: Если я правильно понял ангельский, у самого атакующего с... 06.10.08 10:19   Автор: lazy_anty Статус: Незарегистрированный пользователь <"чистая" ссылка> Если я правильно понял ангельский, у самого атакующего с каналом все в порядке =)) Просто при помощи манипуляции с данными он дает понять ответной стороне, что канал между ними становится все тоньше и тоньше, а скорость все меньше и меньше. И атакуемый хост соглашается подождать... пару лет )) В отличие от синфлуда, с которым сетевые экраны умеют бороться достаточно эффективно на основании формально заданного порога, отражение этой атаки потребует экспертного мнения - порвать конкретное входящее медленное соединение или нет. Так, уже теплее... 06.10.08 15:50   Автор: HandleX <Александр Майборода> Статус: Elderman <"чистая" ссылка> Ну хорошо, понизили скорость передачи данных для одного конкретного соединения до минимума. Что это даёт? Разве это ухудшит процесс передачи данных для других соедений? Дальше-то что делать с «медляками»? -)) Не ухудшит. Но на непропатченных по количеству соединений... 09.10.08 11:33   Автор: lazy_anty Статус: Незарегистрированный пользователь <"чистая" ссылка> > конкретного соединения до минимума. Что это даёт? Разве это > ухудшит процесс передачи данных для других соедений? Не ухудшит. Но на непропатченных по количеству соединений системах количество соединений быстро исчерпается. > Дальше-то что делать с «медляками»? -)) А это хозяину атакуемой системы решать, в принципе - может, у него фильма гигабайтная медленно тянется, а мы её автоматом... того...? ;) каждое tcp-соединение кушает ресурсы. Если в довесок к "медленному" подключению шмякнуть выборочную отправку фрагментов (selective ASK), то кол-во ресурсов на соединение может стать заметным. При большом количестве таких соединений сервер исчерпает ОЗУ. 06.10.08 23:14   Автор: kstati <Eugeny Borisov> Статус: Member <"чистая" ссылка> Кстати, а вот снижение скорости потока особым видом ICMP пакетов регулируется? 07.10.08 07:07   Автор: HandleX <Александр Майборода> Статус: Elderman Отредактировано 07.10.08 08:30  Количество правок: 1 <"чистая" ссылка> Я это к тому, что крыжик вендовозного файрвола, отвечающий за разрешение обработки таких пакетов, по умолчанию отключён. Значит ли это, что венда с включенным файром с такими параметрами не подвержена данному виду атаки? Совершенно верно . Если я не ошибаюсь, то эта проблема решается элементарной блокировкой ICMP type4 (Source Quench Message) Описанном в RFC 777 18.10.08 14:58   Автор: kstati <Eugeny Borisov> Статус: Member <"чистая" ссылка> Вы меня удивляете. ICMP из внешнего мира лучше вообще... 20.10.08 16:23   Автор: TRESPASSER[CfK] <Chaos fon Kernel> Статус: Junior Member <"чистая" ссылка> Вы меня удивляете. ICMP из внешнего мира лучше вообще отключать. И большинство так и делает... It is not true. For instance, PMTU discovery might be very... 25.10.08 19:21   Автор: void <Grebnev Valery> Статус: Senior Member <"чистая" ссылка> > Вы меня удивляете. ICMP из внешнего мира лучше вообще > отключать. It is not true. For instance, PMTU discovery might be very usefull. ICMP uses type 3, code 4 for this purpose. И большинство так и делает... I disagree. For instance you can filter ICMP redirection messages, but leave the rest if needed. Agree? ok. u r right. 26.10.08 15:13   Автор: trespasser]cfk] Статус: Незарегистрированный пользователь <"чистая" ссылка> Ой, какие мы гуру! ;) Отключать всё нафиг без разбора )). Посмотрел бы я как ты отлаживаешь запутанный роутинг без того же пинга. 20.10.08 17:26   Автор: kstati <Eugeny Borisov> Статус: Member Отредактировано 20.10.08 17:37  Количество правок: 2 <"чистая" ссылка> Все, говоришь, отключают ICMP и ты туда же? ;) >tracert bugtraq.ru $traceroute bugtraq.ru На гуру не претендовал. Большинство сайтов которым требуется... 21.10.08 11:36   Автор: TRESPASSER[CfK] <Chaos fon Kernel> Статус: Junior Member Отредактировано 21.10.08 11:47  Количество правок: 2 <"чистая" ссылка> > Все, говоришь, отключают ICMP и ты туда же? ;) > >tracert bugtraq.ru > $traceroute bugtraq.ru На гуру не претендовал. Большинство сайтов которым требуется повышенная безопасность блокируют ICMP. А маршрутизация разумеется отлаживается с включенным. Это как debug информация в файле, которая потом удаляется при финальной сборке. =^р PS по крайней мере флаги типа destination unreachable. Если их будет много, на сервере достигнется предельное число потоков например. И тут достаточно сложно ИМХО отличить атакующий и честный коннект 06.10.08 18:52   Автор: Ustin <Ustin> Статус: Senior Member <"чистая" ссылка> По ссылке не ходил, и в тексте новости не сказано, в чём суть данной уязвимости. Мож кто скажет в двух словах? 02.10.08 14:22   Автор: HandleX <Александр Майборода> Статус: Elderman Отредактировано 02.10.08 14:25  Количество правок: 1 <"чистая" ссылка> Cразу же сяду писать эксплойт :-D (Шутка) Читайте первоисточники. Иногда информация не то чтобы навиду, но явная. Кратко говоря -- доверительные отношения TCP к клиентам губительны. В первоисточнике есть теория действительно не популярного(но используемого) DoS. ИМХО, это не ново - просто шум. 02.10.08 20:31   Автор: kstati <Eugeny Borisov> Статус: Member <"чистая" ссылка> варианты: google -> tcp снижение скорости потока rfc; TCP Selective ACK 04.10.08 20:29   Автор: kstati <Eugeny Borisov> Статус: Member Отредактировано 04.10.08 20:48  Количество правок: 2 <"чистая" ссылка> One technique they describe is to behave as if their connection were getting slower and slower to the point that the TCP stack is tricked into believing it will take years to complete the transmission of data. This forces the TCP stack to keep trying for years to send just a few bytes. http://erratasec.blogspot.com/2008/10/tcp-dos-probably-real.html I'm seeing something unexpected, though. When clients are downloading large files, the servers aren't immediately retransmitting the lost packets. The file download past the gap continues for a very long time. So far, I've seen the file download continue for 3-megabytes before the server goes back and fills in the gap. This can be easily 20 seconds later. http://erratasec.blogspot.com/2008/10/tcp-selective-ack-considered-evil.html Сходил по ссылке. Как я понял, там написано, что стек TCP... 03.10.08 10:13   Автор: HandleX <Александр Майборода> Статус: Elderman <"чистая" ссылка> Сходил по ссылке. Как я понял, там написано, что стек TCP выделяет память под сущность "Соединение" после (syn, syn-ack, ack) цикла рукопожатия. Но моей светлой голове непонятно, как сидя на "не очень толстом канале" можно вынудить стек TCP/IP атакуемого хоста навыделять столько памяти под эти сущности, чтобы атакуемый хост сдохх. Пусть атакующий последний ack не посылает и оставляет... 03.10.08 19:47   Автор: ZloyShaman <ZloyShaman> Статус: Senior Member <"чистая" ссылка> > Сходил по ссылке. Как я понял, там написано, что стек TCP > выделяет память под сущность "Соединение" после (syn, > syn-ack, ack) цикла рукопожатия. > Но моей светлой голове непонятно, как сидя на "не очень > толстом канале" можно вынудить стек TCP/IP атакуемого хоста > навыделять столько памяти под эти сущности, чтобы атакуемый > хост сдохх. Пусть атакующий последний ack не посылает и оставляет соединение полуоткрытым. И так тысячу миллионов раз. Сам он, конечно, в своей реализации стека про эти полуоткрытые должен сразу забывать. Хотя где-то это я уже видел, хе-хе. Ну дык синфлуду поболе чем 10 лет 03.10.08 21:58   Автор: amirul <Serge> Статус: Elderman <"чистая" ссылка> http://en.wikipedia.org/wiki/SYN_flooding Угу, и от него защищается любой мальски себя уважающий файрвол. Раз такие большие пацаны расшумелись - наверное правда что-то нетривиальное. Или (хотя маловероятно) - самореклама 03.10.08 22:22   Автор: Ustin <Ustin> Статус: Senior Member Отредактировано 03.10.08 22:23  Количество правок: 1 <"чистая" ссылка> I think you are right. 25.10.08 19:25   Автор: void <Grebnev Valery> Статус: Senior Member <"чистая" ссылка> Вот из-за таких шутников вряд ли они раскроют даже общие... 02.10.08 14:32   Автор: sattva Статус: Незарегистрированный пользователь <"чистая" ссылка> > Cразу же сяду писать эксплойт :-D (Шутка) Вот из-за таких шутников вряд ли они раскроют даже общие черты проблемы. Специалисту хватит и поверхностного описания, чтобы независимо установить точную причину.

<добавить комментарий>