Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 125
>Такой вывод сделал Artem Dinaburg
>На DEF CON выступление Артура
Так всётаки Артур или Артём?
>На DEF CON выступление Артура
Так всётаки Артур или Артём?
ни разу такого не было.
Какого? Как фиксировали отсутствие случаев? Какой у вас rate dns-запросов к домену?
Ошибка памяти случается раз в несколько лет, кроме того даже для того что бы избежать этой небольшой вероятности в серверном оборудовании используется память с коррекцией ошибок, что позволяет корректировать одиночные ошибки, а вероятность двойной намного меньше. Теперь учтите вероятность того, что «испортится» именно бит в DNS запросе, а не любой другой из гигабайтов информации. И теперь добавим вероятность, что результат именно этой случайной ошибки был предусмотрен злоумышленниками и уже после этого оцените угрозу.
Вероятность ничтожная на мой взгляд и вся проблема выглядит высосанной из пальца. Проще человеческий фактор использовать.
Вероятность ничтожная на мой взгляд и вся проблема выглядит высосанной из пальца. Проще человеческий фактор использовать.
Т.е. все-таки почитать текст топика показалось лишним, да?
А что в моем комментарии вас навело на такие мысли?
То, что комментарий состоит из теории на 100%. А топик про практику. Feel the difference.
В топике не предоставленно никакой статистики по практике, кроме «какой ужас, какой кошмар». Для начала, даже не ясно сколько реально ошибочных запросов он получил, и сколько из них были реальной угрозой безопасности. Кроме того, при передаче важных данных обычно не полагаются только на соединение, как бы и так допускается, что третье лицо может перехватить информацию и не только, а используются дополнительные способы обеспечения безопасности. В общем пока ничего нового.
А причём тут сервер?
Поясню, а то минусами закидают: ошибка будет чаще возникать у клиентов, которых много и которых никакого контроля памяти нет. Именно они и будут обращаться к mic2osoft.com
В статье же есть слова: «от неверно перенаправленных DNS-запросов, до запросов на обновления Windows.» Запросы на обновления Windows, по-вашему, от сервера шли?
В статье же есть слова: «от неверно перенаправленных DNS-запросов, до запросов на обновления Windows.» Запросы на обновления Windows, по-вашему, от сервера шли?
вики говорит про 1 проблему в месяц на 1 гбайт ОЗУ
В данный момент говорит
Если взять по минимуму (25 тыс), то на 1 ГБ — 0.2 ошибки за час. На 32 ГБ — 6.55 ошибки за час. За день это минимум 157 ошибок.
Если из этих 32 ГБ критичными будут только 300 МБ, это всё-равно от 1.5 ошибки за день. Если считать самые критичные 30 МБ, то 5 ошибок за месяц.
Исследование, проведённое на большом количестве серверов Google, показало, что количество ошибок может быть в пределах от 25 000 до 70 000 ошибок за миллиард рабочих часов (англ. device hours) на мегабит (то есть 2,5-7,0 × 10⁻¹¹ ошибок / бит·час)[8].
Если взять по минимуму (25 тыс), то на 1 ГБ — 0.2 ошибки за час. На 32 ГБ — 6.55 ошибки за час. За день это минимум 157 ошибок.
Если из этих 32 ГБ критичными будут только 300 МБ, это всё-равно от 1.5 ошибки за день. Если считать самые критичные 30 МБ, то 5 ошибок за месяц.
Когда я в последний раз имел отношение к сисадминской работе, рейт запросов к домену был около 400req/s, более 30 миллионов в сутки в среднем. Но этого явно недостаточно, чтобы почувствовать эффект от битсквоттинга.
Я сам полон скепсиса и высказал это и в топике и в комментариях, но тем не менее, я все же чувствую, что проблема не столь иллюзорна, как ее тут опустили местные теоретики, начитавшиеся википедии.
Время нас рассудит.
Я сам полон скепсиса и высказал это и в топике и в комментариях, но тем не менее, я все же чувствую, что проблема не столь иллюзорна, как ее тут опустили местные теоретики, начитавшиеся википедии.
Время нас рассудит.
ни разу такого не было.
… и вот снова…
… и вот снова…
А где же конкретные данные статистики обращения к этому «сбойному» ДНСу? По 2м ссылкам «вглубь» чисел тоже нет.
[irony]на серверных объемах оперативки, конечно, да, велика вероятность переворачивания именно этого бита[/irony]
Я надеюсь, результаты сбора статистики по таким запросам будут доступны.
Впрочем, никто и вам не мешает зарегистрировать пару подобных доменов и посмотреть. В статье подчеркивается, что речь исключительно про сверхпопулярные домены с десятками миллиардов запросов в сутки.
Впрочем, никто и вам не мешает зарегистрировать пару подобных доменов и посмотреть. В статье подчеркивается, что речь исключительно про сверхпопулярные домены с десятками миллиардов запросов в сутки.
наверное он увеличил свои шансы зарегистрировав побольше доменов
Где-то на просторах читал, что в эксперименте (с одним типом памяти; возможно, она была китайской) было 12 ошибок в сутки на 1 Гб. При росте объёма памяти растёт и количество ошибок (при приблизительно том же матожидании на 1 Гб). «Этот» бит может быть и не одним, всё же DNS-запрос обрабатывается не за один такт, и не в одной ячейке памяти. Кроме того, настройки латентности операций с памятью в BIOS придумали не просто так. Не думаю, что где-то здесь есть повод для иронии.
А память на серьезные сервера уже принято без ECC брать?
Проблема кажется надуманной.
Да и крайне малая вероятность, что перевернется именно этот бит данных. Да и само перевертывание — событие крайне редкое.
Проблема кажется надуманной.
Да и крайне малая вероятность, что перевернется именно этот бит данных. Да и само перевертывание — событие крайне редкое.
вероятность «переворота» бита в памяти, тем более серверного оборудования с ECC совершенно незначительна. может быть, речь идет об ошибках в ходе передачи пакетов по UDP, в это еще можно как-то поверить.
Судя по известной информации, чел говорит именно про ошибки оперативки (да и название bit-squatting как бы дает понять). Вопрос занятный, без результатов сбора статистики трудно что-то сказать.
Тут речь возможно идет о перевороте бита еще на стороне клиента перед посылкой запроса к ДНС, а оперативка у клиентов совсем не ECC.
https разве не решает такую возможность?
если у серьезного сервиса нет возможности https, то это — печалька.
если у серьезного сервиса нет возможности https, то это — печалька.
DNS-запросы не передаются по https обычно.
Если исказится только DNS запрос, то это будет аналог обычной MITM-атаки с DNS-spoofingом. При этом, если сайт защищен SSL, то браузер покажет нарушение безопасности.
SSL на самом деле дает неплохую защиту против MITM, и наиболее частая практика — перенаправление пользователя на незашифрованное соединение (sslstrip).
Подробнее почитать можно например тут
Или почитать на хабре тут
SSL на самом деле дает неплохую защиту против MITM, и наиболее частая практика — перенаправление пользователя на незашифрованное соединение (sslstrip).
Подробнее почитать можно например тут
Или почитать на хабре тут
в UDP также считается контрольная сумма
Да что ж такое-то, никто не читает текст, только заголовки?
Еще раз рекомендую все же прочитать, не простыня ведь, маленькая заметка.
Ну, это ваш выбор, можете и обосраться, никто не запретит.
Юзеры будут качать, например, вирусы вместо нужного софта.
Применений для злоумышленников масса.
Применений для злоумышленников масса.
Вам вроде привели пример уже. Сегодня зарегистрируют битсквотные домены по числу букв в слове facebook, завтра владельцам доменов пойдут запросы с куками юзеров, в количестве, например, 0,0001% от всех запросов к facebook.com. Послезавтра захваченные аккаунты будут проданы кому-нибудь, а ещё через день New York Times разместит передовицу об этом, и акции facebook упадут на 5%. Миллионы долларов
750 проданных аккаунтов. скандалы, интриги, расследования.
Такое происходит ежедневно. Пользователь, сидя в фейсбуке развёлся/обосрался/покончил с собой -> «Послезавтра захваченные аккаунты будут проданы кому-нибудь, а ещё через день New York Times разместит передовицу об этом, и акции facebook упадут на 5%. Миллионы долларов»
Таким образом, если этот один-единственный бит случайно «перевернулся» в сбойном чипе, то пользователь уже отправляет данные бит-сквоттеру, а не в Microsoft.
правда, как в этих данных что-то откопать, не очень ясно
Какая-то хтуйня. Не первое апреля же.
> Забудьте фишинг, забудьте киберсквоттинг, забудьте тайп-сквоттинг,
Такое ощущение, что проблема «чисто теоретическая», не имеющая с реальностью почти ничего общего.
В реальном мире высоконагруженные сервера не из хлама собирают, и за ПО следят. Вероятность перевернутого бита — стремится к нулю. Да и я вообще сомневаюсь о возможности искажения данных таким способом на современном ПО и HW. Я не железячник, но я подозреваю, что подобные искажения быстрее вызовут железный аналог какого дибудь «Kernel Panic» и повторение процедуры, нежели переход на дрцгой домен.
Опять же выше говорили по ECC, а мне еще помнится что уровень абстракции между железом и ПО уже давно не позволяет подобное. Вспомните что происходит с ОС, когда перегревается CPU. Я думаю от этого еще ни у кого «ворд не запустился».
Поправте меня, если я не прав.
Такое ощущение, что проблема «чисто теоретическая», не имеющая с реальностью почти ничего общего.
В реальном мире высоконагруженные сервера не из хлама собирают, и за ПО следят. Вероятность перевернутого бита — стремится к нулю. Да и я вообще сомневаюсь о возможности искажения данных таким способом на современном ПО и HW. Я не железячник, но я подозреваю, что подобные искажения быстрее вызовут железный аналог какого дибудь «Kernel Panic» и повторение процедуры, нежели переход на дрцгой домен.
Опять же выше говорили по ECC, а мне еще помнится что уровень абстракции между железом и ПО уже давно не позволяет подобное. Вспомните что происходит с ОС, когда перегревается CPU. Я думаю от этого еще ни у кого «ворд не запустился».
Поправте меня, если я не прав.
В теории все так, а чел взял и проверил на практике.
пуф в студию!
Пруфы в Вегасе пока, доклад на DefCon будет послезавтра. Вы тоже не читаете топик перед тем, как комментировать? Я часто страдаю этим, да, все тороплюсь.
Простите мне мое занудство, но какраз я топики и комменты читаю все, и даже заминусованые.
Вы говорите что он на практике это показал, а лишь вижу что он зарегид кучку доменов и пришел к каким-то шокирующим и удивительным результатам.
Я на заборе тоже написать могу много чего…
Вы говорите что он на практике это показал, а лишь вижу что он зарегид кучку доменов и пришел к каким-то шокирующим и удивительным результатам.
Я на заборе тоже написать могу много чего…
ОК, пиши на заборе, но пригласят ли тебя на DefCon и BlackHat, если за надписями ничего нет, м?
Это риторический вопрос, я считаю.
Вы там были? Я нет, и не думаю что буду, но думаю что эта конфа ничем не отлечается от любой другой кроме тематики. Поэтому дождемся сначала доклада, а потом будем думать.
Я вообще не об этом говорил, если Вы не зметили, а о том, что топик из разряда «Мне вчера Михалыч сказал...». Ничего против я не имею, но Ваши комментарии во мне «зажгли огонек».
Жду от вас продолжения в части освещения деталий угорозы.
Вы там были? Я нет, и не думаю что буду, но думаю что эта конфа ничем не отлечается от любой другой кроме тематики. Поэтому дождемся сначала доклада, а потом будем думать.
Я вообще не об этом говорил, если Вы не зметили, а о том, что топик из разряда «Мне вчера Михалыч сказал...». Ничего против я не имею, но Ваши комментарии во мне «зажгли огонек».
Жду от вас продолжения в части освещения деталий угорозы.
Таки сперва добейся? Вы могли бы подождать, пока материалы с конкретными числами появятся в доступе и опубликовать их. Пока что топик действительно выглядит как «АААА! Мы все умрем».
В любом случае, здесь нет владельцев доменов, которых эта проблема затронет.
а еще мне подумалось, что
> Я надеюсь убедить аудиторию, что бит-сквоттинг и другие атаки,…
… и немного на этом заработать/попиариться.
Нормально я считаю.
> Я надеюсь убедить аудиторию, что бит-сквоттинг и другие атаки,…
… и немного на этом заработать/попиариться.
Нормально я считаю.
Вероятность перевернутого бита перевернутого бита — стремится к нулю. Да и я вообще сомневаюсь о возможности искажения данных таким способом на современном ПО и HW
Напрасно сомневаетесь. Это вполне реальная ситуация, вы никогда не задумывались, почему контрольная сумма вычисляется не на одном уровне, а по крайней мере на 4-5 уровнях?
подобные искажения быстрее вызовут железный аналог какого дибудь «Kernel Panic» и повторение процедуры, нежели переход на дрцгой домен
Если у вас на компе уже было 100 Kernel Panic, то есть шанс, что и обращение к битому домену тоже происходило, просто его довольно трудно заметить.
Дважды перевернутый бит уже не считается перевернутым =)
А если по существу — то нормальные катрочки умеют считать чексуммы сами, а еще есть такие штуки как IPS, которыми загораживает Вас провайдер, а провайдера — его првайдер и так далее на L2/L3/L4.
Да и производители железа не стоят на месте. Давно уже используются помехоустойчивые технологии в производстве сетевых устройств.
Не спорю — вероятность есть, хоть и малая, но возможна она на очень дрквнем железе, которое уже затруднительно использовать.
Вопрос другой — как это (тема доклада) можно использовать в коммерческих или иных корыстных целях, учитывая, что более чем 90% устройств, подключеных в сеть, я уверен, являются боле-менее современными и произведены не раньше 2000 года.
А если по существу — то нормальные катрочки умеют считать чексуммы сами, а еще есть такие штуки как IPS, которыми загораживает Вас провайдер, а провайдера — его првайдер и так далее на L2/L3/L4.
Да и производители железа не стоят на месте. Давно уже используются помехоустойчивые технологии в производстве сетевых устройств.
Не спорю — вероятность есть, хоть и малая, но возможна она на очень дрквнем железе, которое уже затруднительно использовать.
Вопрос другой — как это (тема доклада) можно использовать в коммерческих или иных корыстных целях, учитывая, что более чем 90% устройств, подключеных в сеть, я уверен, являются боле-менее современными и произведены не раньше 2000 года.
забыл добавить, что речь я веду о сетевом уровне, как об одном из методов защиты от подобных «атак».
То что касается RAM — явообще не касаюсь, так как современные процессоры и ОС добольно давно научились противостоять подобным сбоям. И случись это сейсас — я бы посчитал это жэкзотикой из разряда очевидное-невероятное, нежели угрозой вселенского масштаба.
PS — и да, коли мы заговорили о необъяснимых вещах, может мне кто объяснит, почему принтеры реагируют на мое приближение, и принтер, зависший в процессе печати, после его осмотра несколькими админами, начинает печать тольок после моего приближения ближе чем на 1,5 метра?
Я не шучу.
То что касается RAM — явообще не касаюсь, так как современные процессоры и ОС добольно давно научились противостоять подобным сбоям. И случись это сейсас — я бы посчитал это жэкзотикой из разряда очевидное-невероятное, нежели угрозой вселенского масштаба.
PS — и да, коли мы заговорили о необъяснимых вещах, может мне кто объяснит, почему принтеры реагируют на мое приближение, и принтер, зависший в процессе печати, после его осмотра несколькими админами, начинает печать тольок после моего приближения ближе чем на 1,5 метра?
Я не шучу.
А если по существу — то нормальные катрочки умеют считать чексуммы сами, а еще есть такие штуки как IPS, которыми загораживает Вас провайдер, а провайдера — его првайдер и так далее на L2/L3/L4.
И все-таки еще повторю — контроль целостности данных производится на ВСЕХ уровнях. В современных файловых системах проверка целостности постоянно усложняется.
Давно уже используются помехоустойчивые технологии в производстве сетевых устройств.
помехоустойчивость может быть и стала выше, однако объем данных вырос на несколько порядков. В абсолютных величинах современные жесткие диски и память порождают существенно бОльшее количество ошибок.
Поправляем: бит-сквотинг возможен, однако с данными которые никоим образом не являются управляющими. Т.е. только с пользовательскими данными, с наполнением каких-то ячеек. Все остальное, конечно же, вызовет исключительную ситуацию и прочие контрольные суммы не дадут пройти нестандарту. А вот с доменным именем — очень даже, теоретически. Вероятность мала, да.
Не того надо бояться, если уж кто-нибудь хочет бояться. А например того, что если уж где-то в памяти случился сбой в одном бите, что вместо операции чтения сектора с диска запустится его форматирование.
>место операции чтения сектора с диска запустится его форматирование.
ну зачем вы пишете херню? операция чтения — вызов к ядерному драйверу, форматирование — запуск юзерспейсового процесса.
ну зачем вы пишете херню? операция чтения — вызов к ядерному драйверу, форматирование — запуск юзерспейсового процесса.
Вот прямо в области памяти, используемой драйвером шины, к которой подключен жесткий диск, из-за сбоя и произойдет смена ОпКода. Теоретически возможно.
Практически — винты «внезапно» «сами» становятся запароленными.
ОпКод форматирования — это мощно
По моему какой-то бред… где именно может быть сбой «ячейки ОЗУ»? Сам TCP имеет контрольную сумму… На серваках в основном память с ECC… Снова таки большинство важного трафика идет через SSL, который заметит разницу в имени домена (сертификат выдается для конкретного домена).
В общем звучит как «а вот представьте себе что если… и еще… при этом… но и не....»
В общем звучит как «а вот представьте себе что если… и еще… при этом… но и не....»
1. Вы набираете (на своем компьютере, без ECC) адрес в строке своего браузера
2. Этот dns адрес помещается в некую область памяти
3. Потом (допустим) происходит «Bit-squatting» и в памяти оказывается совсем другой адрес
4. Далее вызывается какой-нибудь gethostbyname
5. DNS-сервера корректно отрабатывают запрос к другому домену
6. На выходе из функции вы получаете совсем другой ip-адрес
вполне такая теоретическая угроза
2. Этот dns адрес помещается в некую область памяти
3. Потом (допустим) происходит «Bit-squatting» и в памяти оказывается совсем другой адрес
4. Далее вызывается какой-нибудь gethostbyname
5. DNS-сервера корректно отрабатывают запрос к другому домену
6. На выходе из функции вы получаете совсем другой ip-адрес
вполне такая теоретическая угроза
7. Броузер обращается по этому ип и пытается вытянуть сертификат
8. Сертификат выдан на другой ресурс, чем Вы набрали в строке броузера
9. Броузер отказывается отображать ресурс (или выдает предупреждение об опасности), так как домен запрашиваемого ресурса не совпадает с тем, который в сертификате.
Я не знаю, передает ли Майкрософт апдейты через SSL, но в большинстве операционок апдейты идут всегда через безопасные каналы.
Так что при условии использования SSL все-таки не понятно как этот «bit-sqatting» может работать.
8. Сертификат выдан на другой ресурс, чем Вы набрали в строке броузера
9. Броузер отказывается отображать ресурс (или выдает предупреждение об опасности), так как домен запрашиваемого ресурса не совпадает с тем, который в сертификате.
Я не знаю, передает ли Майкрософт апдейты через SSL, но в большинстве операционок апдейты идут всегда через безопасные каналы.
Так что при условии использования SSL все-таки не понятно как этот «bit-sqatting» может работать.
Даже если считать проблему не высосанной из пальца, заголовок гласит «Bit-squatting – свежая угроза для владельцев популярных доменов» я так понимаю речь идет о доменах уровня microsoft, twitter, facebook, vkontakte etc.
И да, bondbig, топик я весь прочитал.
И да, bondbig, топик я весь прочитал.
Помоему бред, вероятность того что произойдет переворот бита, да еще и одного конкретного, да и с учетом того что в большинстве серверов стоит ECC, вероятность крайне мала, скорее нас захватят и пороботят инопланетяне
Хотел проверить на twitter.com, но <зловещийголос>все домены, отличающиеся на один бит, уже заняты</зловещийголос>
Да его сервер просто боты сканировали, скорее всего.
Всё круто, но в статье нет того, чего каждый читающий ожидает: нет цифр.
Отлично. Вполне вероятно, что это кто-то из хабравчан -)
Причем забаненный
Кстати, .ru отличается от .su на один бит.
«Defective internet hardware» разве будет «Неисправное железо в интернет-серверах»? Вернее всего вообще оборудование, а не сервера. Нет?
От контроля четности в микросхемах памяти стали отказываться уже в 90х годах для повышения быстродействия, надежность позволяла, в результате выше быстродействие и меньше стоимость.
Читая коменты выше, некоторые пишут — как же может повредить владельцу домена? Ответ очевиден — репутацией сервиса на этом домене. Т.к. если у клиента на машине будет этот bit-squatting, то в один перкрасный момент кукиса клиента уйдет не туда, куда хотел клиент. И в этот же момент он может лишиться своего аккаунта на этом сервисе.
Забудьте про фишинг… новая угроза, о которой стоит беспокоиться Beer-squatting
Я как-то так цифоркой в номере ошибся и кому-то счет мобильника на 6 баксов пополнил по кредитке.
Я как-то так цифоркой в номере ошибся и кому-то счет мобильника на 6 баксов пополнил по кредитке.
иду зарегаю пару сотен доменов из списка самых популярных… но вот какой бид перевернется?
Напомнило историю о Вояджере-2 ria.ru/science/20100524/237976195.html
Негодный вброс. Пытаются стимулировать продажи доменов.
Интересно, с чего автор решил, что паразитный трафик на домене — следствие битовых ошибок? Наиболее вероятная его причина — активность вирусов. И запросы на обновление Windows идут, потому что что-то нашёл уязвимость в обновлялке и тупо сканирует сеть в поисках чужих серверов обновления. Посмотрите логи любого сервера — там этого вирусного хлама вагон наберётся.
Такая ЭПИЧЕСКАЯ ХРЕНЬ!!! Ничего более высосанного из пальца не видел!
Меня только смущает репутация конференций, на которых был произнесен доклад. Обычно на таких мероприятиях чушь не несут.
Только из-за этого, я задумался и не прошел мимо.
Только из-за этого, я задумался и не прошел мимо.
В том-то все и дело. Данный перевод — всего лишь анонс результатов исследования, причем его результаты впечатлили комиссию двух очень уважаемых конференций, именно там Камински рассказывал про dns poisoning, в который тоже никто не верил, в том числе и многие эксперты, вплоть до выступления.
Однако мня уже линчевали практически. Несколько обидно за зашоренный взгляд хабражителей. Надеюсь, еще не все здесь потеряли способность мыслить немного шире привычных, устоявшихся понятий и стереотипов. Только такие люди делают в жизни что-то действительно стоящее. Пока же я вижу лишь толпу скептиков-теоретиков, которые понабежали и наплевали в профиль, хотя топик получил неплохую оценку.
Однако мня уже линчевали практически. Несколько обидно за зашоренный взгляд хабражителей. Надеюсь, еще не все здесь потеряли способность мыслить немного шире привычных, устоявшихся понятий и стереотипов. Только такие люди делают в жизни что-то действительно стоящее. Пока же я вижу лишь толпу скептиков-теоретиков, которые понабежали и наплевали в профиль, хотя топик получил неплохую оценку.
Шокирующие цифры (как они будут видимо): 90% всех неверных DNS запросов генерировал 0.001% всех машин. Где то 3% могли быть вызваны инверсией бита после многократной ретрансляции пакета при прохождении марштрутизации через «шредер» узлы (процент ошибок будет сильно варьироваться от направления). Длинные имена доменов более подвержены подобной проблеме, но суффиксы (.com, .ru) и префиксы (www., images.) — берут на себя часть нагрузки по несовпадениям (на основе этого может быть произведена оценка достоверности инфы самим microsoft и иже с ним). Часть реверсов может происходить по вине некорректно функционирующих многопоточных приложений и неверно реализованной операции zero buffer copy для DMA каналов. Итоговые проблемы памяти на нормальном железе (где ОС не сыпется каждые 5 минут) могут составлять менее 0.000001%.
Автор оригинального англоязычного топика празднует первое апреля по марсианскому календарю? :)
Сейчас Хабр и другие ресурсы на которых появилась эта новость накрутят ему на mic2osoft «ошибок памяти».
Проблема переворачивания битов в памяти из-за космической радиации не такая уж и надуманная как кажется.
www.ewh.ieee.org/r6/scv/rl/articles/ser-050323-talk-ref.pdf
4MB (~38Mbit) SRAM => ~38000 FIT or ~0.32 fails/year without
protection. With 1 bit ECC correction the uncorrected SER is less
the 2000 FIT and less than 1 FIT with sufficient bit spacing.
Т.е. 327 ошибок в год для 4 гигабайт памяти без ECC (цифра вероятно больше для дешевой памяти из недостаточно очищенных сплавов). Это существенная цифра, но большинство этих ошибок будут пойманы методами коррекции на разных уровнях, что делает вероятность такого сквоттинга несущественной.
www.tezzaron.com/about/papers/soft_errors_1_1_secure.pdf
www.ewh.ieee.org/r6/scv/rl/articles/ser-050323-talk-ref.pdf
4MB (~38Mbit) SRAM => ~38000 FIT or ~0.32 fails/year without
protection. With 1 bit ECC correction the uncorrected SER is less
the 2000 FIT and less than 1 FIT with sufficient bit spacing.
Т.е. 327 ошибок в год для 4 гигабайт памяти без ECC (цифра вероятно больше для дешевой памяти из недостаточно очищенных сплавов). Это существенная цифра, но большинство этих ошибок будут пойманы методами коррекции на разных уровнях, что делает вероятность такого сквоттинга несущественной.
www.tezzaron.com/about/papers/soft_errors_1_1_secure.pdf
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Bit-squatting – свежая угроза для владельцев популярных доменов