https://bugtraq.ru/review/archive/2012/19-01-12.html

Symantec признала взлом своей сети в 2006 году; Игровой плагин для Visual Studio; Фундаментальная проблема в Oracle; Квартальные патчи Oracle: махнула ли компания рукой на безопасность своей базы? Потенциальная массовая кража паролей в LiveJournal.

#312, 19.01.2012

Symantec признала взлом своей сети в 2006 году
dl // 19.01.12 20:35
После обещания индийскими взломщиками из группы Dharmaraja опубликовать исходный код ряда продуктов Symantec, компания некоторое время пыталась сохранить лицо и утверждала, что код этот был получен из неких третьих рук, после взлома какого-нибудь партнера и т.п.

Однако теперь Symantec все-таки признала, что код Norton Antivirus Corporate Edition, Norton Internet Security, Norton Utilities, Norton GoBack и pcAnywhere был украден непосредственно из корпоративной сети в 2006 году. Представители компании, уверяют, что кража кода шестилетней давности никак не отразится на пользователях современных продуктов компании, однако аналитики не столь оптимистичны.

Собственно, даже сам представитель Symantec Крис Паден (Cris Paden) заметил, что пользователи pcAnywhere могут столкнуться со слегка возросшим риском. Именно к пользователям этого продукта сейчас привлечено повышенное внимание поддержки Symantec; перехват контроля за средством удаленного управления - штука, мягко говоря, малоприятная.
Источник: Reuters

Игровой плагин для Visual Studio
dl // 19.01.12 19:46
Microsoft выпустила плагин, позволяющий разнообразить жизнь в Visual Studio. Теперь можно соревноваться с коллегами непосредственно в процессе кодирования и коллекционировать всякие добрые достижения. Так, бэджик "Go To Hell" дается за использование оператора goto, "Cheater" за вызов меню IntelliTrace 10 раз, "Field Master" за 100 полей в классе и т.п.
Источник: GeekWire, Visual Studio Achievements

Фундаментальная проблема в Oracle
dl // 18.01.12 17:46
В продолжение темы оракловых неприятностей InfoWorld публикует материал о проблеме, частично устраненной в последнем обновлении, но принципиально не исчезнувшей.

Источником проблемы является счетчик System Change Number (SCN), увеличивающийся при каждой операции над базой, и являющийся критичным для ее работы. Такие встроенные часы, идущие только вперед, причем для увеличения одной базой SCN другой нужны лишь самые базовые привилегии.

Проектировщики заложили вполне приличный запас в SCN, сделав его 48-битным. Верхней границы в 281,474,976,710,656 должно хватить надолго, но помимо этого, на SCN было наложено дополнительное ограничение - в каждый момент времени его значение не может превышать количество секунд, прошедших с 1.01.1980, умноженное на 16,384. Предполагалось, что баз, непрерывно живущих с 80 года, и проводящих по 16 тысяч транзакций в секунду, в природе не существует.

На практике же обнаружилось несколько ситуаций, в которых природу удавалось обойти:

1. Баг в бэкапе. Базы Oracle поддерживают так называемый hot backup, позволяющй с помощью команды ALTER DATABASE BEGIN BACKUP начать бэкап работающей базы. Ошибка в кодировании привела к тому, что после выполнения этой команды SCN начинал расти со страшной скоростью, не останавливаясь даже после команды END BACKUP. На одиночной базе даже это не вызвало бы проблем, но в сочетании с множественными связанными базами (а у крупных организаций число подобных серверов может идти на сотни) теоретически недостижимый лимит вдруг оказывается не столь недостижимым. Недавно исправленная уязвимость носит номер 12371955, "High SCN growth rate from ALTER DATABASE BEGIN BACKUP in 11g."

2. Саботаж. Описанная ситуация открывает новый вектор атак - пользователь, имеющий доступ к второстепенной базе, может накрутить SCN всех баз, входящих в систему.

До недавнего времени вся реакция от Oracle на описанную проблему сводилась к увеличению ограничения на SCN вдвое - коэффициент умножения секунд вырос до 32,768. Что любопытно, это увеличение само по себе могло и ухудшить ситуацию, если в системе встретятся два сервера, только один из которых пропатчен - у него SCN может превысить критичный уровень для второго, и они просто не смогут взаимодействовать.

Наконец, последние исправления включили некую защиту, названную по словам представителей Oracle прививкой (inoculation). Пока не вполне ясна ее эффективность, как и механизм ее работы, но стоит учесть, что исправление вышло только для последних версий. Все версии, более старые, чем 11.2.0.2.0 и 10.1.0.5, по-прежнему уязвимы.
Источник: InfoWorld

Квартальные патчи Oracle: махнула ли компания рукой на безопасность своей базы?
dl // 18.01.12 16:55
Последнее квартальное обновление Oracle принесло 78 исправленных уязвимостей, лишь две из которых относятся к продуктам Oracle Database. Это бьет предыдущий октябрьский антирекорд из 5 устраненных уязвимостей. В то же время в MySQL было исправлено 27 уязвимостей и 17 - в продуктах, унаследованных от Sun.

Конечно, некорректно говорить об ухудшении ситуации, ориентируясь на уменьшение числа исправленных ошибок - в конце концов, сама Oracle утверждает, что код Oracle Database Server достиг такой зрелости, что до обнаружения принципиально новых векторов атаки там практически нечего будет исправлять.

Однако представитель Application Security's TeamShatter с говорящим именем Alex Rothacker утверждает, что количество ошибок, о которых они сообщают Oracle, осталось на прежнем уровне, только вот исправлять их Oracle не торопится - возможно, после поглощения Sun на свой флагманский продукт уже не хватает времени.
Источник: InfoWorld, Oracle

Потенциальная массовая кража паролей в LiveJournal
dl // 15.01.12 13:46
Поначалу мне показалось, что симптомы похожи на внедрение постороннего кода в стили, используемые рядом аккаунтов (у себя, например, я этого не наблюдаю, но на многих лентах вылезает при просмотре из-под любого аккаунта). Скорее всего, все было еще проще - в чей-то пост был воткнут div во весь экран, и все, у кого он показался в ленте друзей, дружно перезашли и размножили его в вирусном стиле по своим друзьям, а те понесли знамя дальше. Так что хочется передать отдельный горячий привет ljшной фильтрации.

В результате при попытке просмотра ленты друзей пользователь получает страницу с характерной синей ljшной шапкой с формой для логина и продублированной ей же на девственно чистой белой странице (в отличие от обычной страницы входа, забитой всяким хламом). В формах в качестве action указан совершенно посторонний адрес. При просмотре кода страницы видно, что оригинальная лента друзей никуда не делась, а просто перекрыта слоем с этой явно фишинговой формой.

Указанный в форме адрес http://ohtoenequ1.getenjoyment.net/index.php к настоящему моменту уже как бы благополучно прилег, видимо, не выдержав толпы запросов, но до этого могло быть собрано очень немало паролей. С другой стороны, на заборе-то написать можно что угодно, и фишинговый скрипт запросто может выводить подобное сообщение в целях маскировки под ставшие традиционными ljшные падения. Так что нет оснований считать, что сбор паролей не продолжается.

Потенциальным жертвам (к которым относятся все, у кого происходили непонятые выбрасывания на форму с логином), разумеется, стоит немедленно сменить пароль, обращая внимание на содержимое адресной строки.

В качестве временной меры, позволяющей изголодавшимся юзерам добраться до содержимого своей ленты, можно просто добавить ?nohtml=1 к ее url.
Источник: msado lj