https://bugtraq.ru/review/archive/2011/14-05-11.html

Facebook вводит двухфакторную авторизацию; 10 лет BugTraq.Ru; Милиции предложено проверить 115 тысяч зомби; Британские ученые (tm) обнаружили в iPhone давно известный секретный файл; Религиозный спор вокруг memcpy и glibc.

#299, 14.05.2011

Facebook вводит двухфакторную авторизацию
dl // 13.05.11 16:50
Через несколько месяцев после Google Facebook анонсировал функцию Login Approvals, обеспечивающую двухфакторную авторизацию. Реализация вполне традиционна - после включения соответствующей настройки при попытке входа с неавторизованного ранее устройства/компьютера потребуется ввод кода, отправленного через SMS на привязанный к аккаунту телефон. Авторизация может быть как однократной, так и постоянной (с возможностью отмены).
Источник: Facebook

10 лет BugTraq.Ru
dl // 07.05.11 23:25
Строго говоря, домен bugtraq.ru был зарегистрирован еще осенью 2000 года, но, во-первых, до мая 2001 на нем в лучшем случае висела заглушка о скором запуске, а во-вторых, про тот юбилей я просто забыл.

Ну а с 7 мая 2001 можно отсчитывать реальное существование сайта, поскольку именно тогда я решил, что скрипт форума дорос до открытия к нему публичного доступа, о чем наглядно свидетельствует сообщение с ID=1.
Источник: первое сообщение форума

Милиции предложено проверить 115 тысяч зомби
dl // 04.05.11 18:19
ООО "ДДОС ЗАЩИТА" занимающееся защитой сайтов от DDoS-атак, подало в УВД Брянска заявление с приложением в виде списка из 115407 IP-адресов, с которых осуществлялись запросы от вредоносных программ, участвующих в DDoS-атаках, ставших в последнее время серьезной головной болью для многих сайтов - т.е. действия, подпадающие под 273-ю статью УК РФ. В заявлении предлагается установить владельцев терминалов с установленным вредоносным ПО, провести проверку и принять меры к виновным.

Понятно, что владельцы этих компьютеров в большинстве своем и не подозревают о своем участии в подобных атаках, и традиционно их принято считать (почти) невинными жертвами. Однако "ДДОС ЗАЩИТА" считает, что надо разбираться и с ними (или по крайней мере с их провайдерами, не реагирующими на многочисленные предупреждения).

Список адресов отсортирован по провайдерам, так что подобное заявление не стоит рассматривать как попытку DDoS доблестной милиции :) Хотя интересно, чем все это закончится.
Источник: копия заявления, отчет по атакам

Британские ученые (tm) обнаружили в iPhone давно известный секретный файл
dl // 21.04.11 11:54
На днях очередные британские исследователи напугали общественность рассказом о том, что iPhone записывает в файл consolidated.db всю информацию о перемещениях устройства. Честно говоря, не вполне понятно это внезапное (не менее tm) искреннее удивление "как, apple за нами следит" - существование этого файла вовсе не является тайной за семью печатями и обсуждается на профильных форумах по крайней мере полгода. Ну разве что сейчас это оформили доступной всем программкой.

Немного о том, зачем это используется - на форуме (спасибо Александру Майбороде aka HandleX).
Источник: O'Reilly Radar

Религиозный спор вокруг memcpy и glibc
dl // 31.03.11 14:51
Любопытная и поучительная история разворачивается вокруг одного обновления glibc, добравшись в последние дни и до рунетовских площадок.

Предыстория восходит к далеким K&R временам, когда в стандартной библиотеке появились функции memcpy и memmove, отличающиеся поведением при обработке перекрывающихся регионов. В зависимости от расположения областей перекрытия можно обеспечить корректную работу, запустив копирование от начала либо от конца. Согласно стандарту, memmove такие проверки делает, memcpy - нет (во имя борьбы за производительность), и ее поведение в таких ситуациях не определено, хотя исторически сложилось так, что все реализации memcpy используют копирование "от начала".

Собственно же история началась в конце прошлого года, когда очередное обновление Fedora сломало 64-битный Adobe Flash. Через некоторое время выяснилось, что причина поломки - выполненная с подачи Intel'овских инженеров оптимизация memcpy в glibc, которая теперь иногда стала выполняться "от конца", обеспечивая на некоторых процессорах выигрыш в скорости в полтора-два раза.

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

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

Согласно более компромиссной позиции, представленной Линусом Торвальдсом, все-таки нехорошо оставлять крайним пользователя, которому по барабану, что там внутри, но который точно знает, что после обновления системы у него ломается Flash. Хотите бороться за производительность - воткните всю оптимизацию внутрь memmove, а memcpy просто превратите в ее алиас - все равно там теперь полно проверок, которых раньше не было в исходной memcpy, и ради отсутствия которых ее поведение и оказалось неопределенным. Т.е. идея в том, что вполне можно добиться того же роста производительности, не ломая совместимость. Хотя и это не совсем так - за 40 с лишним лет существования С наверняка нашлись программисты, использующие привычное поведение memcpy наизнанку - не для копирования, а для размножения шаблона по буферу. Но их уже совсем не жалко.

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

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

P.S. Кстати, есть еще какие-то вопросы по поводу того, почему Линукс никогда не завоюет десктопы?
Источник: Red Hat Bugzilla, via avva lj