информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Где водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / обзор / архив / 2011
АРХИВ
главная
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997






Подписка:
BuqTraq: Обзор
RSN
РВС
БСК




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




обсудить  |  все отзывы (0)
[32934]

анонимность клоуны конференции спам уязвимости .net acrobat activex adobe android apple beta bgp bitcoin blaster borland botnet chrome cisco crypto ctf ddos dmca dnet dns dos dropbox eclipse ecurrency eeye elcomsoft excel facebook firefox flash freebsd fsf github gnome google gpl hp https ibm icq ie intel ios iphone java javascript l0pht leak linux livejournal mac mcafee meltdown microsoft mozilla mysql netware nginx novell ny open source opera oracle os/2 outlook password patch php powerpoint programming pwn2own quicktime rc5 redhat retro rip router rsa safari sco secunia server service pack shopping skype smb solaris sony spyware sql injection ssh ssl stuff sun symantec torrents unix virus vista vmware vpn wikipedia windows word xp xss yahoo yandex youtube



Rambler's Top100
Рейтинг@Mail.ru



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


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach