Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Не понимаешь? Плати!

Open source
Диалог в багзилле стандартной библиотеки си glibc. Один человек не понимает, что то, что он считает багом, таковым не является. Второй не имеет желания «разжевывать» это первому, хотя с охотой дает советы получить объяснения за плату. Ну а затем подтянулись тролли… Грубость наказуема.

Извиняюсь за английский, перевод убил бы всю прелесть беседы джентельменов.
# Stop reopening bugs. Search the web if you want an explanation, I don't have anything handy and certainly have no interest in writing it up.
> I have tried to search the web already and found nothing. If you want to close bugs as INVALID/WORKSFORME, please provide a proper explanation.
# Strange, I never saw your name on my paycheck. Since if that's not the case you cannot order me around.

# Stop reopening the bug. If you want explanations pay somebody.

> Paid $1 via paypal. Trans ID 3H4989806A1962407. Please fix.

> Is this open source terrorism? «Pay us money or the bug stays!»

# Fine. Whatever. I'll revert it, assholes.
Всего голосов 42: ↑34 и ↓8+26
Просмотры744
Комментарии 79

Боремся с "*** glibc detected ***"

Настройка Linux
Привет, хабрасообщество!

Хочу рассказать о небольшой проблеме, с которой сегодня столкнулся.
Бывает, программа валится, выдавая строку, начинающуюся с "*** glibc detected ***" и сопровождающуюся большим количеством служебной информации. Дело в том, что в glibc есть собственный менеджер памяти, который в случае попытки освобождения невыделенной памяти начинает паниковать и думать, что порушились внутренние структуры менеджера памяти.

Конечно, правильным путем решения тут будет отдебажить программу, найти ошибку и/или сообщить об этом разработчику. Но иногда результат нужен срочно, и нет времени заниматься этим. В этом случае можно попробовать переключить менеджер памяти glibc в другой режим, менее производительный, но более устойчивый к подобным ошибкам программистов. Сделать это можно так:

MALLOC_CHECK_=0 /path/to/program


Значение «0» заставляет полностью игнорировать подобные ошибки, «1» — выводить сообщения о них в stderr, «2» — завершать программу при обнаружении ошибки.
Работает в Linux libc новее, чем 5.4.23 и GNU libc 2.x.
Всего голосов 14: ↑13 и ↓1+12
Просмотры5.1K
Комментарии 3

Смешная уязвимость в MySQL под Linux 64-bit

Информационная безопасностьMySQL
В субботу координатор по безопасности проекта MariaDB Сергей Голубчик (petropavel) сообщил об интересной уязвимости в MySQL/MariaDB до версий 5.1.61, 5.2.11, 5.3.5, 5.5.22.

Суть в том, что при подключении пользователя MariaDB/MySQL вычисляется токен (SHA от пароля и хэша), который сравнивается с ожидаемым значением. При этом функция memcmp() должна возвращать значение в диапазоне -128..127, но на некоторых платформах (похоже, в glibc в Linux с оптимизацией под SSE) возвращаемое значение может выпадать из диапазона.

В итоге, в 1 случае из 256 процедура сравнения хэша с ожидаемым значением всегда возвращает значение true, независимо от хэша. Другими словами, система уязвима перед случайным паролем с вероятностью 1/256.
Читать дальше →
Всего голосов 96: ↑90 и ↓6+84
Просмотры7.7K
Комментарии 92

Эксперимент по проверке библиотеки glibc

Блог компании PVS-StudioC
glibc and PVS-Studio
Мы провели эксперимент по проверке библиотеки glibc с помощью PVS-Studio. Цель эксперимента посмотреть, насколько успешно анализатор может проверять Linux-проекты. Пока плохо может. Возникает огромное количество ложных срабатываний из-за использования нестандартных расширений. Однако, всё равно удалось найти кое что интересное.
Читать дальше →
Всего голосов 108: ↑93 и ↓15+78
Просмотры22K
Комментарии 63

GHOST — уязвимость gethostbyname() в glibc

Блог компании Digital SecurityИнформационная безопасность
Специалисты Qualys сообщили о наличии уязвимости в gethostbyname() и gethostbyname2() в GNU
C Library (glibc), которая, как минимум в одном случае, способна привести к удаленному выполнению кода. Уязвимость позволяет перезаписать до 4 байт на 32-битных системах и до 8 байт на 64-битных системах в куче числами (0…9), точкой (.) и NULL-символом (0x00).

Уязвимость появилась в версии glibc-2.2 от 10 ноября 2000 года и была закрыта в версии 21 мая 2013 года с glibc-2.18, поэтому уязвимы только LTS-дистрибутивы Linux: Debian 7, Red Hat Enterprise Linux 6 и 7, CentOS 6 и 7, Ubuntu 12.04.

Уязвимым является код, который отвечает за получение hostname. Для перезаписи кучи, имя хоста должно удовлетворять следующим условиям:
  • Содержать в себе только цифры и точку
  • Первый символ должен быть цифрой
  • Последний символ не должен быть точкой
  • Быть достаточно длинным, чтобы переполнить буфер (>1КБ)
Читать дальше →
Всего голосов 30: ↑27 и ↓3+24
Просмотры18K
Комментарии 25

Новая уязвимость GHOST угрожает популярным дистрибутивам на базе Linux

Блог компании Positive TechnologiesИнформационная безопасность
image

Уязвимость в распространенных дистрибутивах Linux может позволить злоумышленнику получить удаленный контроль над системой. Под ударом оказались пользователи Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04. Также уязвимы Zend Framework v2, Wordpress и ряд других популярных приложений.

Информация о новой уязвимости (CVE-2015-0235) в библиотеке glibc (GNU C Library) впервые была опубликована во французской рассылке. Некоторые специалисты считают, что это было сделано по ошибке, так как к тому моменту никто не успел подготовить обновления.

Подробное техническое описание уязвимости и эксплойт для уязвимости можно найти на Openwall, а первые описания были опубликованы в сообществе Rapid 7.
Читать дальше →
Всего голосов 49: ↑41 и ↓8+33
Просмотры43K
Комментарии 28

Ghost, неужели опять?!

Блог компании Kerio Technologies

Всем привет!


Уже много слов было сказано о «новой» уязвимости библиотеки glibc с загадочным названием Ghost.

По этой причине не буду отнимать ваше время на описание и возможные варианты устранения уязвимости ваших подопечных систем, но предложу немного информации по устранению данной уязвимости в наших продуктах, Kerio Connect, Kerio Control и Kerio Operator.

Читать дальше →
Всего голосов 13: ↑5 и ↓8-3
Просмотры4.5K
Комментарии 0

Нестандартный топ новостей о безопасности: Январь

Блог компании «Лаборатория Касперского»Информационная безопасность
Всем привет! После успешного дайджеста новостей за 2014 год мы решили сделать рубрику регулярной, точнее – ежемесячной. Сегодня – самые важные новости информационной безопасности за январь. Методика выбора новостей немного изменилась. Мы по-прежнему берем самые посещаемые новости с нашего сайта Threatpost и пытаемся понять, почему они удостоились такого внимания. Но в ежемесячном дайджесте новостей будет пять. Напоминаю, что на Threatpost мы собираем все новости индустрии информационной безопасности. Собственные исследования «Лаборатории» публикуются на сайте Securelist.

Краткое содержание: Дыра в glibc и почему физики не дружат с лириками, северокорейский браузер, зарядка-кейлоггер и дыры в клавиатурах, криптолокеры в целом и в частности, взлом WiFi с социальной инженерией.
Поехали!
Всего голосов 31: ↑26 и ↓5+21
Просмотры12K
Комментарии 14

Нестандартный топ событий в сфере IT-безопасности 2015

Блог компании «Лаборатория Касперского»Информационная безопасность
Вот и пришло время повторить упражнение, которое я первый раз выполнил ровно год назад. Тогда я взял 10 самых популярных новостей с нашего сайта Threatpost и попытался выяснить — почему именно они, собственно, привлекли внимание общественности — и специалистов, и обычных пользователей. Такой метод имеет очевидные недостатки — на популярность статей много что влияет, и совершенно не обязательно, что самые популярные новости об инцидентах в кибермире являются одновременно и самыми важными. Но есть и достоинства: событий в сфере информационной безопасности происходит огромное количество, и каждый участник их обсуждения, в зависимости от специализации и личных интересов, выберет свои «самые-самые». А тут — если и не самый объективный, то хотя бы независимый инструмент оценки.

В этом году подборка самых посещаемых новостей удачно делится на пять основных категорий:
— Низкотехнологичные угрозы для пользователей
— «Уязвимости в неожиданных местах»: безопасность «интернета вещей», домашних и промышленных сетевых устройств,
— Проблемы шифрования данных
— Громкие уязвимости в ключевых платформах и «хайтек» киберугроз — примеры самых продвинутых атак
— Рутинные, но опасные уязвимости в распространенном софте

Вот по ним и пройдемся.
Читать дальше →
Всего голосов 11: ↑9 и ↓2+7
Просмотры12K
Комментарии 3

Критическая уязвимость библиотеки glibc позволяет осуществлять удаленное выполнение кода

Блог компании Positive TechnologiesИнформационная безопасностьРазработка под Linux


Исследователи Google обнаружили критическую уязвимость в библиотеке glibc (GNU C Library). В функции getaddrinfo(), которая отвечает за разбор доменных имен, происходит переполнение буфера — ошибка позволяет злоумышленникам осуществлять удаленное выполнение кода.

Эксплуатация уязвимости, получившей обозначение CVE-2015-7547, возможна в случаях, когда уязвимые устройства или приложения отправляют запросы контролируемым хакерами доменам и серверам, а также в случае проведения атаки типа man-in-the-middle.
Читать дальше →
Всего голосов 43: ↑41 и ↓2+39
Просмотры28K
Комментарии 36

Security Week 07: Apple против ФБР, глобальная уязвимость в glibc, криптолокеры и медицина

Блог компании «Лаборатория Касперского»Информационная безопасность
Неделя с лишним рабочим днем выдалась насыщенной и сбалансированной. События вокруг спора между Apple и американскими госорганами в лице ФБР и Минюста продолжают развиваться, но уже сейчас ясно, что они серьезно повлияют на развитие индустрии безопасности в части защиты личной информации. В отличие от этой чисто политической истории, критическая уязвимость в библиотеке glibc представляет собой новость абсолютно техническую, но, прямо или косвенно, тоже затрагивает всех.

Хочется сказать, что на этой неделе активизировался спор за возможность влиять на развитие технологий: между, так сказать, технарями и гуманитариямиполитиками. Первые руководствуются возможностью реализовать ту или иную функциональность в софте и железе, вторые — необходимостью договариваться с различными заинтересованными сторонами. На самом деле спорят не об этом. Технологии всегда развиваются независимо от того, согласны ли с этим окружающие или нет. Выводя свой спор с ФБР в общественное пространство, Apple борется за то, чтобы оставаться в авангарде этого самого технического развития. Иными словами, если Apple проиграет, и реальная (а то и воображаемая!) защищенность устройств компании каким-то образом пострадает, это не значит, что за всеми нами обязательно будет следить большой брат. Это значит, что условный вымпел с надписью «самый безопасный смартфон» перехватит какая-то другая компания.

Впрочем, это только гипотеза. Не исключено, что пока мы все бурно обсуждаем взлом зашифрованных данных, кто-то где-то копает очередную критическую дыру в очередной glibc, и когда докопает — все остальное по теме безопасности станет вообще неактуально. Рассмотрим оба случая подробнее. Все выпуски дайджеста доступны по тегу.
Читать дальше →
Всего голосов 16: ↑13 и ↓3+10
Просмотры18K
Комментарии 20

Security Week 51-52: Нестандартный топ новостей 2016

Блог компании «Лаборатория Касперского»Информационная безопасность
Ну вот опять, никто не ожидал, а год внезапно закончился. Пора подводить итоги, и уже третий год подряд я предпочитаю делать это нестандартно. Единственным критерием для отбора новости в топ является ее популярность на новостном сайте Threatpost. Да, это не самый объективный способ оценки важности того или иного события. Но и не самый плохой: аудитория Threatpost обычно игнорирует откровенную политоту и уделяет немало внимания событиям, на которые нужно реагировать либо вот прямо сейчас, либо тем, что стоит запомнить на будущее.

Напомню, в обзоре за 2015 год у нас были уязвимости в интернете вещей (ну ладно, в роутерах), шифрование данных, серьезная уязвимость Stagefright в Android и дыра в GLIBC, а также сложносочиненные атаки — Carbanak и The Equation. В 2014-м: уязвимость POODLE в SSLv3, Shellshock и Heartbleed и, внезапно, стеганография PNG-картинками.

В этом году «пятерка» популярных новостей выглядит отчасти похоже: дело Apple против ФБР, дыры в GLIBC (опять!) и в ядре Linux, проблемы с OAuth и вопросы генерации надежных случайных чисел из ненадежных источников.
Читать дальше →
Всего голосов 19: ↑19 и ↓0+19
Просмотры5.5K
Комментарии 2

Тернистый путь Hello World

C++AssemblerCРазработка под Linux
Tutorial
Recovery mode

Вдохновение на написание данной статьи было получено после прочтения похожей публикации для архитектуры x86 [1].


Данный материал поможет тем, кто хочет понять, как устроены программы изнутри, что происходит до входа в main и для чего всё это делается. Также я покажу как можно использовать некоторые особенности библиотеки glibc. И в конце, как и в оригинальной статье [1] будет визуально представлен пройденный путь. В большинстве своём статья представляет собой разбор библиотеки glibc.


Итак, начнём наш поход. Будем использовать Linux x86-64, а в качестве инструмента отладки — lldb. Также иногда будем дизассемблировать программу при помощи objdump.


Исходным текстом будет обычный Hello, world (hello.cpp):


#include <iostream>
int main()
{
        std::cout << "Hello, world!" << std::endl;
}
Читать дальше →
Всего голосов 76: ↑75 и ↓1+74
Просмотры28K
Комментарии 4

Resolve IP адресов в Linux: понятное и детальное описание

*nixСерверное администрированиеIPv6Разработка под LinuxDevOps

Настройка сетевого взаимодействия сервисов не самая простая задача и часто осуществляется без глубокого понимания как требуется настраивать систему и какие настройки на что влияют. После миграции сервисов в docker контейнерах с centos 6 на centos 7 я столкнулся со странным поведением вебсервера: он пытался присоединиться к сервису по IPv6, а сервис же слушал только IPv4 адрес. Стандартный совет в такой ситуации — отключить поддержку IPv6. Но это не поможет в ряде случаев. Каких? В этой статье я задался целью собрать и детально объяснить как приложения resolve'ят адреса.

Читать дальше →
Всего голосов 28: ↑28 и ↓0+28
Просмотры67K
Комментарии 6

Как Linux'овский sort сортирует строки

Системное администрированиеПрограммированиеРазработка под Linux
Tutorial

Введение


Всё началось с короткого скрипта, который должен был объединить информацию об адресах e-mail сотрудников, полученных из списка пользователей почтовой рассылки, с должностями сотрудников, полученными из базы отдела кадров. Оба списка были экспортированы в текстовые файлы в кодировке Юникод UTF-8 и сохранены с юниксовскими концами строк.


Содержимое mail.txt


Иванов Андрей;ia@example.com

Содержимое buhg.txt


Иванова Алла;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Абаканов Михаил;маляр

Для объединения файлы были отсортированы юниксовской командой sort и поданы на вход юниксовской программе join, которая неожиданно завершилась с ошибкой:


$> sort buhg.txt > buhg.srt
$> sort mail.txt > mail.srt
$> join buhg.srt mail.srt > result
join: buhg.srt:4: is not sorted: Иванов Андрей;слесарь

Просмотр результата сортировки глазами показал, что в целом сортировка правильная, но в случае совпадений мужских и женских фамилий, женские идут перед мужскими:


$> sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарь

Выглядит как глюк сортировки в Юникоде или как проявление феминизма в алгоритме сортировки. Первое, конечно, правдоподобнее.

Читать дальше →
Всего голосов 123: ↑123 и ↓0+123
Просмотры15K
Комментарии 12

История двух стандартных библиотек Си

Ненормальное программированиеПрограммированиеАнализ и проектирование системСистемное программирование
Перевод
Сегодня мне пришел баг-репорт от пользователя Debian, который скормил какую-то ерунду в утилиту scdoc и получил SIGSEGV. Исследование проблемы позволило мне провести отличное сравнение между musl libc и glibc. Для начала посмотрим на стектрейс:

==26267==ERROR: AddressSanitizer: SEGV on unknown address 0x7f9925764184
(pc 0x0000004c5d4d bp 0x000000000002 sp 0x7ffe7f8574d0 T0)
==26267==The signal is caused by a READ memory access.
    0 0x4c5d4d in parse_text /scdoc/src/main.c:223:61
    1 0x4c476c in parse_document /scdoc/src/main.c
    2 0x4c3544 in main /scdoc/src/main.c:763:2
    3 0x7f99252ab0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
    4 0x41b3fd in _start (/scdoc/scdoc+0x41b3fd)

В исходниках на данной строчке написано вот что:

if (!isalnum(last) || ((p->flags & FORMAT_UNDERLINE) && !isalnum(next))) {

Подсказка: p — это корректный, ненулевой указатель. Переменные last и next имеют тип uint32_t. Сегфолт случается на втором вызове функции isalnum. И, самое важное: воспроизводится только при использовании glibc, но не musl libc. Если вам пришлось перечитать код несколько раз, вы не одиноки: тут попросту нечему вызывать сегфолт.
Читать дальше →
Всего голосов 75: ↑71 и ↓4+67
Просмотры16K
Комментарии 75