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

DoS атака против файловой системы Btrfs, opennews (??), 13-Дек-12, (0) [смотреть все] Готова к продакшену, да Поздравлямс сусю , ryoken (?), 20:29 , 13-Дек-12, (2) +54 // http www opennet ru opennews art shtml num 35561в таком варианте вполне , ананим (?), 20:44 , 13-Дек-12, (6) // Вы точно читать умеете Хранилище, это там где положили и хранят Корень, это та, BratSinot (?), 21:03 , 13-Дек-12, (13) –13 // Если корень это там, где что-то постоянно меняется, то расскажи как нам милок, ч, Анонище (?), 21:14 , 13-Дек-12, (19) +1 Так тенденция же идет к тому, что не будет ни каких тебе var usr и пр , будет , Аноним (-), 21:28 , 13-Дек-12, (25) –8 это называется 8212 объяснение прописных истин корень 8212 это такое м, ананим (?), 22:19 , 13-Дек-12, (40) +4 code testparm SHARA path read only No force dire, pavlinux (ok), 23:03 , 13-Дек-12, (52) –6 А некоторые еще и через костры прыгают, в прорубь зимой ныряют, делают татуировк, Аноним (-), 11:00 , 14-Дек-12, (95) +6 gt оверквотинг удален А, может, самба зачрутована Не убедил , Аноним (-), 14:21 , 14-Дек-12, (97) Или запихана в LXC В KVM-виртуалке , Аноним (-), 17:33 , 14-Дек-12, (110) на бездисковом сервере , pavlinux (ok), 02:24 , 18-Дек-12, (157) +1 http lists busybox net pipermail busybox 2010-December 074114 htmlhttp www o, Аноним (-), 13:42 , 15-Дек-12, (139) Вы с дубу рухнули, где таких админов откопали , GentooBoy (ok), 08:41 , 14-Дек-12, (88) –3 А систему то как апдейтить , anonymous (??), 21:36 , 13-Дек-12, (31) –2 У вас систему злоумышленник апдейтит , Аноним (-), 22:17 , 13-Дек-12, (38) +13 вот нелегко нам злоумышленникам все время палки в колеса подлые админы вставляю, Яйцассыром (?), 04:32 , 14-Дек-12, (79) +8 в цитаты , Аноним (-), 11:02 , 14-Дек-12, (96) +1 var это tmpfs, очевидно же, 1 (??), 08:22 , 14-Дек-12, (86) –2 Прядочная женщина любит порядок сегод7я один, завтра другой Потаскуха - потоск, Аноним (-), 09:22 , 14-Дек-12, (91) +1 Выпустят патч и ФС приблизиться к идеалу еще на шажок , SubGun (ok), 21:03 , 13-Дек-12, (12) +3 // zfs ещ в 2011 от такого страдала и ни чё так, 7 лет в продакшене Dhttp www , ананим (?), 22:23 , 13-Дек-12, (42) +4 // Только так и не видно его, продакшна этого, вот в чём соль , AlexAT (ok), 22:56 , 13-Дек-12, (50) –1 Лиц пубертатного возраста к продакшену не допускают , iZEN (ok), 23:04 , 13-Дек-12, (53) Видимо да, в этом и причина , AlexAT (ok), 23:07 , 13-Дек-12, (54) +2 По тебе заметно , Аноним (-), 23:08 , 13-Дек-12, (55) +2 Если так, то у ZFS нет шансов в продакшене , Аноним (-), 23:28 , 15-Дек-12, (140) +1 у вас странный продакшен - Только не надо отмазываться рассказывая про универс, linux must _RIP_ (?), 16:21 , 14-Дек-12, (103) –2 Не, ну что вы, как можно Продакшн - это изен, у которого пул из 3 дисков 18Мб с, Аноним (-), 00:07 , 16-Дек-12, (142) +1 Оракл сперва поздравь , filosofem (ok), 22:42 , 13-Дек-12, (49) –2 // zfs не crc32 использует А вполне себе SHA-256, чтоб ты знал Где-где тама колли, Аноним (-), 14:22 , 14-Дек-12, (98) –1 // SHA256, говоришь Как там с загрузкой CPU при создании 100500 файлов в каталоге , AlexAT (ok), 14:32 , 14-Дек-12, (99) +1 По-моему эти ламерюги элементарно перепутали хэши которые внутренняя функция хэш, Аноним (-), 17:43 , 14-Дек-12, (113) Он пониже спалился, угу checksum on 124 off 124 fletcher2, 124 fletcher4, AlexAT (ok), 17:46 , 14-Дек-12, (114) +1 Уймись уже Контрольная сумма 8212 частный случай хэширования , iZEN (ok), 18:30 , 14-Дек-12, (120) –2 Спич был за хэш-таблицы А ты почему-то вспомнил чексуммирование области данных , Аноним (-), 19:36 , 14-Дек-12, (132) У тебя zfs межушного ганглия Не офтопь, тут не про этот чудопепелац новость Ей, filosofem (ok), 14:38 , 14-Дек-12, (100) +2 gt оверквотинг удален Btrfs не сертифицирована для продакшена баз данных http, iZEN (ok), 15:00 , 14-Дек-12, (102) –1 А где был сертифицирован ZFS в бсд Ну или даже в лине Ах, нигде Ну я так и по, Аноним (-), 19:39 , 14-Дек-12, (133) +1 Только в особых случаях 8212 http www freebsd org cgi man cgi query zfs apr, iZEN (ok), 14:57 , 14-Дек-12, (101) –1 Вы что, настолько дятлы что не отличаете хэши используемые как внутренняя функци, Аноним (-), 17:40 , 14-Дек-12, (111) –1 В теории хэш-таблица легко может строиться и деревом на основе SHA-256, почему н, AlexAT (ok), 17:41 , 14-Дек-12, (112) +1 Потому что на практике от такой диверсии хэш-таблица изрядно тормознет Всерьез , Аноним (-), 17:52 , 14-Дек-12, (115) На самом деле я просто использовал хэш-дерево на основе результата MD4 для хране, AlexAT (ok), 17:55 , 14-Дек-12, (116) Вариант, конечно, но кстати MD4 уже и не считается криптостойким - для него колл, Аноним (-), 19:23 , 14-Дек-12, (130) Чексуммирование 8212 частный случай применения хэширования Хэш на основе CRC, iZEN (ok), 18:15 , 14-Дек-12, (118) –2 Только к хэш- b таблицам b все это ну вообще совсем не относится Ни флетчер, , Аноним (-), 19:34 , 14-Дек-12, (131) А что, кто-то утверждал что CRC32, fletcher, SHA-256 в ZFS используется в хэш-та, iZEN (ok), 20:41 , 14-Дек-12, (136) –2 Ну вот и будьте Какой смысл с апломбом вспоминать sha-256 чексуммировние данных, Аноним (-), 00:18 , 16-Дек-12, (143) gt оверквотинг удален Дополню справедливости ради ---Блоки пула дисковой па, iZEN (ok), 18:32 , 14-Дек-12, (121) –1 Разработчики суси уже надоели Всё время совершают какие-то ошибки То ли дело р, Аноним (-), 23:25 , 13-Дек-12, (56) +5 // Толсто Таких не существует в природе , ILYA INDIGO (ok), 05:27 , 14-Дек-12, (80) +5 // http www opennet ru opennews art shtml num 35240commit 2000afe4fb86c374650371f, canonical (?), 07:10 , 14-Дек-12, (81) http www kernel org pub linux kernel v3 0 ChangeLog-3 6 6Признаю, таки существ, ILYA INDIGO (ok), 07:55 , 14-Дек-12, (85) –2 ребят то что не готово к продакшену досить даже не пытаются , Кевин (?), 00:19 , 14-Дек-12, (70) +2 // А в коментах в бложике упоминается что в OpenBSD с использованием похожей т, Аноним (-), 01:01 , 16-Дек-12, (149) ОО и где местные аналитики которые кричали все хорошо , linux must _RIP_ (?), 20:38 , 13-Дек-12, (3) +1 // Ооо, btrfs-у выпала честь от более-менее оригинально мыслящего перца потыкать в , Аноним (-), 21:01 , 13-Дек-12, (10) +5 // атаки на хэши давно известны, их часто используют вспоминаем, например, недавни, all_glory_to_the_hypnotoad (ok), 22:03 , 13-Дек-12, (37) +3 // Взаимоисключающие параграфы детектед Он, конечно, кричит, но в хеш-таблице, Аноним (-), 23:26 , 13-Дек-12, (58) –1 для хэш таблиц никогда не бывает O 1 , именно из-за колизий Не позорьтесь И воп, linux must _RIP_ (?), 16:24 , 14-Дек-12, (104) –1 Вообще-то нормальным сценарием эксплуатации хэш-таблицы является случай когда ко, Аноним (-), 17:59 , 14-Дек-12, (117) Эксперт 294 уровня как всегда газифицировал лужу, побыв для части сведений кэпом, nuclight (??), 19:49 , 14-Дек-12, (134) –2 Много апломба и мало по делу На втором курсе обычно учат тому что нужна какая-, Аноним (-), 00:30 , 16-Дек-12, (144) ага, а костыли 8212 это такие ноги, только альтернативные и экономичные но м, arisu (ok), 21:59 , 20-Дек-12, (160) Никто не говорил, что все идеально Уверен, подобную фишку можно было бы со вс, SubGun (ok), 21:03 , 13-Дек-12, (11) // Насчет всех - это смотреть надо Зависит от юзаемых алгоритмов Потенциально же т, Аноним (-), 21:06 , 13-Дек-12, (15) Для OpenBSD что-то похожее нашли Там же в бложике в коментах немало интересного, Аноним (-), 18:49 , 16-Дек-12, (151) Это вы еще просто не видели перцев с IXBT которые совершенно случайно нашли виде, Аноним (-), 21:12 , 13-Дек-12, (18) // а ссыли нет интересно было бы самому нарезать , Аноним (-), 21:31 , 13-Дек-12, (26) // Вот ссыль на описалово Вместе с объяснением феномена - http www ixbt com opti, Аноним (-), 21:41 , 13-Дек-12, (33) +3 местные аналитики забывают что подобная атака была и на питон и на пхп и на мног, Аноним (-), 20:44 , 13-Дек-12, (5) +2 Это можно сделать не только на Btrfs, в том плане что поедание ресурсов возможно, Аноним (-), 20:54 , 13-Дек-12, (8)   // Это можно сделать много где и это не самый ожидаемый вектор атаки для программис, Аноним (-), 21:04 , 13-Дек-12, (14)   На качественных файловых системах, xfs btree вместо hash , reiserfs на этапе про, svn (??), 21:07 , 13-Дек-12, (16) +1   // А нельзя ли пруф на то что они специально дизайнились с учетом этого фактора А , Аноним (-), 21:14 , 13-Дек-12, (20) +1   // какая-то у вас каша в голове скорость вычисления хэша - вещь константная И то, linux must _RIP_ (?), 21:23 , 13-Дек-12, (23) –1   Просто намеренный гасеж коллизиями вообще-то не является штатным видом эксплуата, Аноним (-), 21:31 , 13-Дек-12, (28) –1   crc32 не является криптохэшем - видимо что бы это узнать нужны дикие познания , linux must _RIP_ (?), 16:33 , 14-Дек-12, (105) –1   Внезапно, хэш-таблицы сами по себе вообще не требуют в общем случае использовани, Аноним (-), 18:24 , 14-Дек-12, (119)   reiserfs использует хеш функцию r5, для которой не известен алгоритм создания ко, svn (??), 21:25 , 13-Дек-12, (24)   В общем то коллизии находят даже для криптостойких функций иногда, а для хэш-таб, Аноним (-), 21:43 , 13-Дек-12, (34)   По ссылке не ходил статью не читал brtfs выдал ошибку на шестьдесят втором файл, svn (??), 22:23 , 13-Дек-12, (41) –1   Не только читал, но и в курсе как хэш таблицы делают Понимаете ли, для хэш-табли, Аноним (-), 23:46 , 13-Дек-12, (61)   Почитай ещё раз То что ты знаешь, не значит что авторы btrfs знают По факту, в, svn (??), 07:35 , 14-Дек-12, (84) –1   остальной бред скипнут В случае применения в FS - там все немного не так как вы, linux must _RIP_ (?), 16:37 , 14-Дек-12, (106) –1   Во первых, простите, а что есть дописать в середину файла Технически я понима, Аноним (-), 18:32 , 14-Дек-12, (122)   Мисье - вы уверены что к директориям примимо слово posix Если уверены - то мне о, linux must _RIP_ (?), 00:10 , 15-Дек-12, (137) –1   Пардон, вы сами про ФАЙЛЫ завели речь На самом деле я просто не понял ваш маневр, Аноним (-), 00:36 , 16-Дек-12, (145)   у ext4 тоже специально предусмотрена обработка колизий в dx tree , linux must _RIP_ (?), 21:20 , 13-Дек-12, (22)   // Проблема не в том что обработки нет А в том что если коллизий будет много, алго, Аноним (-), 21:34 , 13-Дек-12, (29) –1   see up все не так просто , linux must _RIP_ (?), 16:38 , 14-Дек-12, (107) –1   Да, оказывается не все так просто В коментах к бложику продолжается изучение гд, Аноним (-), 01:04 , 16-Дек-12, (150)   Не понятно чего так носятся с этой btrfs, преимуществ никаких, сколько тестов уж, Buy (ok), 21:35 , 13-Дек-12, (30) –1 // Её преимущества не в производительности , Аноним (-), 21:39 , 13-Дек-12, (32) Возятся с ней потому что вот в этом вы не правы Во первых, покажите хоть какую-, Аноним (-), 21:47 , 13-Дек-12, (35) +3 // Показываю для упоротых http zfsonlinux org , iZEN (ok), 22:19 , 13-Дек-12, (39) –8 // Она не работает , Аноним (-), 22:32 , 13-Дек-12, (46) +3 Правда что ли Вот тут запустили http www linux org ru gallery screenshots 85, iZEN (ok), 23:01 , 13-Дек-12, (51) –4 Запорожец с горы Арарат Хорошо пошёл , filosofem (ok), 00:00 , 14-Дек-12, (65) +1 Ubuntu переводится как я не могу настроить Debian , IMHO (?), 00:03 , 14-Дек-12, (66) +1 Казалось бы, при чем тут вообще Лужков W убунту Впрочем, черный пиар - это тоже, Аноним (-), 00:16 , 14-Дек-12, (69) Не, ну почему Как-то работает Вопрос только в том КАК 1 Это не в майнлайне И, Аноним (-), 00:03 , 14-Дек-12, (67) +1 Зачем это им нужно Магия поддержки любых ФС в ZVOL со всеми плюшками ZFS, как , iZEN (ok), 01:03 , 14-Дек-12, (75) –3 Изя, в 2008 она была experimental Плюшки пилятся в illumos zfsonlinux Кстати, , Сержант Скотч (?), 04:24 , 14-Дек-12, (78) Затем Чтобы эту магию попробовать, надо либо с чистого листа начинать, либо п, AlexAT (ok), 07:21 , 14-Дек-12, (83) –1 С 2009 года 8212 http svnweb freebsd org base view revision revision 197221, iZEN (ok), 10:11 , 14-Дек-12, (92) –1 FreeBSD в продакшене Изя как всегда отжигает , slowpoke (?), 10:44 , 14-Дек-12, (94) У него жгучий продакшн с трехдисковым пулом выдающим 18Мб сек А у меня ноутбучн, Аноним (-), 00:38 , 16-Дек-12, (146) +1 Твой винт поддерживает хотя бы дедупликацию блоков ФС, не говоря уж о сквозной ц, iZEN (ok), 09:42 , 17-Дек-12, (152) –1 Мммм трудновато найти мазохиста, готового платить за дедуп 4 кратным падение, AlexAT (ok), 11:55 , 17-Дек-12, (153) +1 А чего же тогда лезет в охотный ряд и сравнивает в принципе известные факты де, iZEN (ok), 18:37 , 17-Дек-12, (155) –2 Блджад Вот сразу видно жабиста Zero knowledge of underlying operations Не у, AlexAT (ok), 19:30 , 17-Дек-12, (156) +2 Ну что поделать Не понимают жабисты как работают компьютеры Это позволяет им к, Аноним (-), 22:24 , 20-Дек-12, (161) +1 Не поэтому scrub бессилен на FAULTED-пуле Но недавно появилась волшебная коман, iZEN (ok), 20:10 , 21-Дек-12, (163) Просто прикольная иллюстрация гибкости в размещении метаданных Оно даже иную ФС, Аноним (-), 18:39 , 14-Дек-12, (123) машинка из TOP10 что-то в первой пятерке - секвоя говорит что работает можно, linux must _RIP_ (?), 16:39 , 14-Дек-12, (108) –1 Да и пусть себе работает А топ10 - это потому что 1 из 500 звучит гораздо мен, Аноним (-), 18:40 , 14-Дек-12, (124) +1 Вы мне покажете еще 10-15P стораджей под btrfs а top10 намекает что размер диск, linux must _RIP_ (?), 00:12 , 15-Дек-12, (138) –1 Один какой-то мегауникальный пепелац в b лаборатории b - это круто и замечате, Аноним (-), 00:44 , 16-Дек-12, (147) А дополнительно для упоротых там подарят мне 32 гб озу если я скачаю сорца zfson, Аноним (-), 22:34 , 13-Дек-12, (47) +2 Тебе ехать или шашечки За что-то нужно чем-то платить , anonymous (??), 08:24 , 14-Дек-12, (87) +1 да все твои уже итак знают ты лучше нормальным покажи кто поддержкой этой каки в, ананим (?), 22:37 , 13-Дек-12, (48) LLNL gov, Intel com мало , linux must _RIP_ (?), 16:39 , 14-Дек-12, (109) –1 Один, два, много Хм где-то я это слышал А, дикари так считали, во , Аноним (-), 18:41 , 14-Дек-12, (125) +1 Спасиб, сами это кушайте , Аноним (-), 23:49 , 13-Дек-12, (62) +2 pvmove разве не тоже самое делает , Аноним (-), 22:31 , 13-Дек-12, (45) +1 // Создание снапшота в lvm2 просаживает производительность тома, который снапшотили, anonymous (??), 23:26 , 13-Дек-12, (57) эта 8230 как его 8230 использование zfs вообще в принципе просаживает и прои, ананим (?), 23:58 , 13-Дек-12, (64) +1 Тем не менее, скорость записи на оную от самого по себе факта наличия снапшота т, Аноним (-), 00:07 , 14-Дек-12, (68) –1 Тем не менее скорость записи на оную падает всегда и ресурсы жрутся тоже всегда,, ананим (?), 01:01 , 14-Дек-12, (74) +1 Простите, падает - это если на ext4 полный журнал врубить А тут аналог полного , Аноним (-), 18:50 , 14-Дек-12, (127) Почитайте про устройство снапшотов в LVM, а потом говорите про уменьшение произв, GentooBoy (ok), 08:53 , 14-Дек-12, (89) –2 Спасибо, я почитал И остаюсь при своем мнении крылья и аэродинамика задуманные, Аноним (-), 18:43 , 14-Дек-12, (126) починилиhttp learnitwithme com p 334, sdog (ok), 02:02 , 14-Дек-12, (77) Хм, на собственном опыте при единственном снэпшоте особой просадки производитель, Анонимный аноним (?), 07:20 , 14-Дек-12, (82) +2 pvmove это не снапшот, это вынуть диск из пула, я же специально цитировал на что, Аноним (-), 10:42 , 14-Дек-12, (93) Помимо производительности, есть соображения удобства администрирования и количес, anonymous (??), 21:50 , 13-Дек-12, (36) // Зачем нужны возмжности, если давно уже есть LVM ext4 , Аноним (-), 23:26 , 13-Дек-12, (59) // Вот вы и юзайте там снапшоты если хотите , Аноним (-), 23:50 , 13-Дек-12, (63) У бтрфс есть еще одно узкое место помимо производительности - пожирание места на, Аноним (-), 00:41 , 14-Дек-12, (72) // Слегка ошибся На 5ТБ данных 10ГБ метаданных А вообще это зависит , filosofem (ok), 00:49 , 14-Дек-12, (73) Хотите прикол Создавайте директории и в них файлы 0-го размера до упора Однажд, Аноним (-), 18:53 , 14-Дек-12, (128) Внезапно, эта величина сильно зависит от среднего размера файлов Потому что инф, Аноним (-), 23:30 , 15-Дек-12, (141) crc32 ну они дали , slowpoke (?), 09:14 , 14-Дек-12, (90) +1 // Для hash table это в принципе вполне себе функция Просто оказалось что в конкре, Аноним (-), 18:55 , 14-Дек-12, (129) // Покажи-ка еще хотя бы парочку известных применений, где CRC32 использовался бы и, nuclight (??), 20:01 , 14-Дек-12, (135) –3 // Насчет CRC32 - увы, я не коллекционировал специально для вас подборку всех реали, Аноним (-), 00:48 , 16-Дек-12, (148) вот такие кулхацкеры и суют её в хэши, ага сейчас я тебе скажу два словосочетан, arisu (ok), 21:08 , 20-Дек-12, (159) хэш crc32 на всякий случай отложил идею пощупать btrfs на 50 лет , arisu (ok), 21:04 , 20-Дек-12, (158) –1 // Лучше на 100 А то вдруг каким-то чудом доживешь еще Как же тогда твой статус н, Аноним (-), 01:58 , 21-Дек-12, (162) +2 2,3,5,8,30,72,90,158

Сообщения

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

8. "DoS атака против файловой системы Btrfs"	+/–
Сообщение от Аноним (-), 13-Дек-12, 20:54
Это можно сделать не только на Btrfs, в том плане что поедание ресурсов возможно не только в данной ФС и не только в ФС
Ответить | Правка | Наверх | Cообщить модератору

	14. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 13-Дек-12, 21:04
	> Это можно сделать не только на Btrfs, в том плане что поедание > ресурсов возможно не только в данной ФС и не только в ФС Это можно сделать много где и это не самый ожидаемый вектор атаки для программистов. В общем то это довольно фундаментальная проблема использующая слабое место хэш-таблиц: при коллизиях хэш-таблица может быть медленной. Если коллизий много - дело дрянь. Атака состоит в потугах сделать так чтобы коллизий стало много. Для криптостойких функций это невозможно, но они слишком медленны для скоростных применений (лукап в структуре ключ-значение в памяти). А вот упрощенные хэши дают достаточно маневра для попыток их проабузить. CRC32 в этом плане очень плох, т.к. алгоритмы подгона CRC32 под ответ ни для кого не секрет.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "DoS атака против файловой системы Btrfs"	+1 +/–
	Сообщение от svn (??), 13-Дек-12, 21:07
	На качественных файловых системах, xfs(btree вместо hash), reiserfs(на этапе проектировки предусмотрена устойчивость к коллизиям) такого сделать не получится.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	20. "DoS атака против файловой системы Btrfs"	+1 +/–
	Сообщение от Аноним (-), 13-Дек-12, 21:14
	> предусмотрена устойчивость к коллизиям) А нельзя ли пруф на то что они специально дизайнились с учетом этого фактора? А то проблема просто есть у целого класса алгоритмов - хэш функций. И задумались о аккуратном подгоне входных данных для их торможения относительно недавно. Явно позже чем указанные ФС проектировались. Что вызывает некие нехорошие подозрения на ваш счет.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от linux must _RIP_ (?), 13-Дек-12, 21:23
	какая-то у вас каша в голове.. скорость вычисления хэша - вещь константная. И то что колизии бывают - нормальный разработчик как бы в курсе.. (достаточно подумать 255 байт ужимают до 32 - тут уж не бывает без вариантов). Другой вопрос что при реализации кто-то заложился что таких колизий не много - но это уже проблемы реализации :-) Которую тут хвалили..
	Ответить | Правка | Наверх | Cообщить модератору

	28. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от Аноним (-), 13-Дек-12, 21:31
	> И то что колизии бывают - нормальный разработчик как бы в курсе.. Просто намеренный гасеж коллизиями вообще-то не является штатным видом эксплуатации ФС. И есть большие сомнения что остальные существующие ФС кто-то хоть как-то изучал под таким углом вообще. Хотя если хочется поисходить на г-но - это круто, конечно, но тогда для справедливости придется полить им и кучу иного софта где эту проблему выловили и зачинили. > (достаточно подумать 255 байт ужимают до 32 Вообще-то CRC32 - это 4 байта. Или 32 бита. Критиканить других с такими познаниями о криптографии - ну да, это круто. > кто-то заложился что таких колизий не много Это совершенно стандартное допущение для реализации хэш-таблиц. Ибо в абсолютно вырожденном случае хэш-таблица вырождается например в линейный список ("ничего кроме коллизий нет"). Нормально? :)
	Ответить | Правка | Наверх | Cообщить модератору

	105. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от linux must _RIP_ (?), 14-Дек-12, 16:33
	>> И то что колизии бывают - нормальный разработчик как бы в курсе.. > Просто намеренный гасеж коллизиями вообще-то не является штатным видом эксплуатации ФС. > И есть большие сомнения что остальные существующие ФС кто-то хоть как-то > изучал под таким углом вообще. Хотя если хочется поисходить на г-но > - это круто, конечно, но тогда для справедливости придется полить им > и кучу иного софта где эту проблему выловили и зачинили. >> (достаточно подумать 255 байт ужимают до 32 > Вообще-то CRC32 - это 4 байта. Или 32 бита. Критиканить других с > такими познаниями о криптографии - ну да, это круто. crc32 не является криптохэшем :-) видимо что бы это узнать нужны дикие познания? а что брякнул до 32 - это было просто пояснение без привязки к конкретному алгоритму - так будет лучше? >> кто-то заложился что таких колизий не много > Это совершенно стандартное допущение для реализации хэш-таблиц. Ибо в абсолютно вырожденном > случае хэш-таблица вырождается например в линейный список ("ничего кроме коллизий нет"). > Нормально? :) формулировка нормальная - только с тем как используются хэш при построении файловых систем - вы не знакомы. Знакомы только с хэшированными списками - но есть и другие варианты - с другими болячками. В случае ext3/4 - к примеру есть дерево хэшей в узлах которого расположены ссылки на имена имеющие одинаковых хэш. В этом случае поиск имени сначала ведется по частичному или полному хэшу от имени - дальше производится модификации блоков которые хранят информацию о именах с одинаковым результатом хэш функции. Вот тут то и приплыли - если колизий будет слишком много - затраты на модификацию этих блоков - могут быть очень и очень большими. (split, merge blocks - и создание дополнительных листьев в дерево). Сдается мне что в случае btrfs идет атака как раз на этот кусок - а улучшением хэш функции (как и увеличением размера хэша) - можно только усложнить подбор имен дающих колизию. Нормально ? :-)
	Ответить | Правка | Наверх | Cообщить модератору

	119. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 14-Дек-12, 18:24
	> crc32 не является криптохэшем :-) видимо что бы это узнать нужны дикие познания? Внезапно, хэш-таблицы сами по себе вообще не требуют в общем случае использования именно криптостойких функций. И для них совергшенно нормально если будет некий процент коллизий. Покуда он небольшой - это мало замедляет работу таблицы. Это считается штатным развитием событий и как правило явно обрабатывается, так что столкнувшиеся записи тем не менее сохраняются и доступны. А вот то что специально нагенеренные оптом коллизии в хэш-таблице можно абузануть для сильного торможения работы чего-либо с злонамеренной целью - намного менее очевидный факт. Требующий не программерского мышления а хакерского. Не "как закрепить рельсу на полотне", а "как сделать так чтобы рельсу не унес первый встречный козел, голыми руками, за минуту". Редкий программер мыслит именно в таком контексте. Где-то это и так прокатывает. А где-то случаются различные приколы. > к конкретному алгоритму - так будет лучше? Отмазался, типа? :) > формулировка нормальная - только с тем как используются хэш при построении файловых > систем - вы не знакомы. Нифига себе апломба. А откуда такой масштабный вывод следует? Из вашего немеряного апломба? Других предпосылок не вижу. > Знакомы только с хэшированными списками - но есть и другие варианты - с другими болячками. Кто вам сказал что я знаком только с хэш-таблицами? Вы сами придумали? > будет слишком много - затраты на модификацию этих блоков - могут > быть очень и очень большими. (split, merge blocks - и создание Ну спасиб, Капитан. Что бы я без вас делал? А еще можно b-деревья юзать, например. Нет хэш-функции - нет проблем с ней. Зато других проблем есть. > (как и увеличением размера хэша) - можно только усложнить подбор имен дающих колизию. Ну так если подобрать коллизию не получится - стало быть и проблема отсутствует. Что мне там не нравится - так это 220 минут взвиса. Похоже на то что алгоритм совсем где-то взвис. Т.е. там видимо еще и просто баг где-то порылся.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от svn (??), 13-Дек-12, 21:25
	reiserfs использует хеш функцию r5, для которой не известен алгоритм создания коллизий. И уж точно (даже если коллизия возникнет) это ограничится проблемой производительности, а не будет отказ в создании файла.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	34. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 13-Дек-12, 21:43
	> И уж точно (даже если коллизия возникнет) В общем то коллизии находят даже для криптостойких функций иногда, а для хэш-таблиц нет требования криптостойкости в общем случае. Хотя как оказалось, такая поблажка может икаться совершенно неожиданным образом. > а не будет отказ в создании файла. Так в btrfs нет отказов при создания файла. Правда есть какое-то непотребное время удаления.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от svn (??), 13-Дек-12, 22:23
	>Так в btrfs нет отказов при создания файла. По ссылке не ходил статью не читал? brtfs выдал ошибку на шестьдесят втором файле с коллизией.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 13-Дек-12, 23:46
	> По ссылке не ходил статью не читал? Не только читал, но и в курсе как хэш таблицы делают. Понимаете ли, для хэш-таблиц сроду не использовали криптографически стойкие функции. Потому что они медленные. Коллизии для хэш-таблиц - нормальное явление. Это как правило не просто допустимо, но и явно обрабатывается. Так что путем того или иного костылинга таблица в результате помнит обе конфликтующие записи и может достать и ту и другую. В общем случае это не создает никаких проблем. Главное чтобы процент коллизий был небольшой. Большой процент коллизий говорит о том что разрядность хэша мала относительно числа элементов и таблица работает неэффективно (приходится смотреть по нескольку записей с одним и тем же хэшом чтобы понять какая из них нужна). Но это не является чем-то совершенно недопустимым. Но как оказалось, при должной изобретательности можно глушить коллизиями прицельно. Спровоцировав очень много коллизий. В этом случае хэш-таблица завалится в дуpной режим, когда она вместо быстрого лукапа по индексу начинает разгрeбать немеряную цепочку коллизий. Большинство алгоритмов хэш-таблиц вообще никогда не дизайнилось с прицелом на учет такой подставы. И на практике такие атаки появились лишь сравнительно недавно.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от svn (??), 14-Дек-12, 07:35
	> Не только читал, но и в курсе как хэш таблицы делают. Почитай ещё раз. То что ты знаешь, не значит что авторы btrfs знают. По факту, в директории btrfs не возможно создать больше 61 файла с одним хешем.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от linux must _RIP_ (?), 14-Дек-12, 16:37
	>> По ссылке не ходил статью не читал? > Не только читал, но и в курсе как хэш таблицы делают. > Но как оказалось, при должной изобретательности можно глушить коллизиями прицельно. Спровоцировав > очень много коллизий. В этом случае хэш-таблица завалится в дуpной режим, > когда она вместо быстрого лукапа по индексу начинает разгрeбать немеряную цепочку > коллизий. остальной бред скипнут. В случае применения в FS - там все немного не так как вы представляете. Собственно очень часто появляется вопрос - который уже тут задавали. "как дописать в середину файла - не переписывая каждый раз его хвост" Создаем большой каталог (hint вспоминаем почему гугл сделал патч на max dir size в ext4) - после чего выбираем новые имена файлов так что бы модификация была где-то в начале - и смотрим на это развлечение.. А учитывая что в btrfs - был заявлен b-tree+ - эта дура может затребовать еще и постоянную балансировку при удалении / создании элемента.. Ну и приплыли... ps. знакомство с хэшами это хорошо - это бонус. Знакомство с предметной областью - все же более привествуется...
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	122. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 14-Дек-12, 18:32
	> Собственно очень часто появляется вопрос - который уже тут задавали. > "как дописать в середину файла - не переписывая каждый раз его хвост" Во первых, простите, а что есть "дописать" в середину файла? Технически я понимаю что CoW это мог бы и это изобразить как 2 пальца об асфальт, но в posix вообще нет вызовов позволяющих ДОписать. Только ПЕРЕЗАПИСАТЬ. Поверх того что было (cow опять же сделает выносок, но это второй вопрос). Во вторых - не особо понятно как дозапись в файл коррелирует с коллизиями вызваными именами файлов. > Создаем большой каталог (hint вспоминаем почему гугл сделал патч на max dir > size в ext4) - после чего выбираем новые имена файлов так > что бы модификация была где-то в начале - и смотрим на это развлечение.. Я что-то не понял: а где тут про дозапись в середину файла? :) А как генерить имена файлов чтобы там коллизии были - я и сам догадаюсь, спасибо. Тем более что у гражданина который это нашел даже скрипт для иллюстрации есть. > ps. знакомство с хэшами это хорошо - это бонус. Знакомство с предметной > областью - все же более привествуется... С хэшами и деревьями я позгнакомился фиг знает когда. И вообще, наезды смотрятся не сильно уместно, особенно с учетом того что вы сами временами какой-то бред с удовольствтем задвигаете.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от linux must _RIP_ (?), 15-Дек-12, 00:10
	Мисье - вы уверены что к директориям примимо слово posix? Если уверены - то мне очень сложно вам будет объяснить что там не так.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 16-Дек-12, 00:36
	> Мисье - вы уверены что к директориям примимо слово posix? Пардон, вы сами про ФАЙЛЫ завели речь: > "как дописать в середину файла - не переписывая каждый раз его хвост" > Если уверены - то мне очень сложно вам будет объяснить что там не так. На самом деле я просто не понял ваш маневр - сначала задвинули про файлы и потом перешли на директории, тихонько спустив тему дозаписи в середину файла на тормозах. Получился какой-то бред, имхо.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от linux must _RIP_ (?), 13-Дек-12, 21:20
	у ext4 тоже специально предусмотрена обработка колизий в dx tree..
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	29. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от Аноним (-), 13-Дек-12, 21:34
	> у ext4 тоже специально предусмотрена обработка колизий в dx tree.. Проблема не в том что обработки нет. А в том что если коллизий будет много, алгоритм очень существенно провалится по скорости относительно "среднего по больнице" поведения. Что позволяет вредителю воткнуть весьма конкретный лом в чей-то вентилятор если коллизии можно более-менее просто посчитать и организовать их появление в системе. А вот дальще система займется их обработкой. В хучшем случае хэш-таблица может деграднуть до чего-то типа линейного списка, со всеми вытекающмим, как то не O(1) а O(N), что уже совсем иной коленкор.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "DoS атака против файловой системы Btrfs"	–1 +/–
	Сообщение от linux must _RIP_ (?), 14-Дек-12, 16:38
	>> у ext4 тоже специально предусмотрена обработка колизий в dx tree.. > Проблема не в том что обработки нет. А в том что если > коллизий будет много, алгоритм очень существенно провалится по скорости относительно "среднего > по больнице" поведения. see up. все не так просто.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "DoS атака против файловой системы Btrfs"	+/–
	Сообщение от Аноним (-), 16-Дек-12, 01:04
	> see up. все не так просто. Да, оказывается не все так просто. В коментах к бложику продолжается изучение где еще можно так поприкалываться. Под внимание попала дефолтная ФС OpenBSD, которую как я понял успешно заDOSили :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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