о баге в openssl и прочих переполнениях буфера

за счет таблицы LDT можно в каждой программе иметь кажется 4096 (или сколько-то там) сегментов памяти

Ты правда думаешь, что всем программам хватит 4096 сегментов (или даже 65536)?

Для буферов, в которые читается извне и есть шанс использования переполнения буфера - вполне должно хватить большинству.

Ты упорот.

Ну а сколько нужно одному приложению буферов для I/O?

сколько нужно одному приложению буферов для I/O?

Из-за твоей общей упоротости я не стану спрашивать, почему ты решил контролировать только I/O.

Удаленный злоумышленник сперва взаимодействует с I/O программы.

Баг в openssl был именно такой, емнип.

В malloc-е уже есть защита от переполнения буфера. OpenSSL предусмотрительно написал workaround, чтобы эта защита не работала. Уж насколько я скептичен по отношению к теориям заговора, но это или крайняя степень безалаберности, или нет.

LibreSSL пока что видится интересной альтернативой. Если его разработчики будут разумны, то OpenSSL умрёт, как в своё время умер XFree и туда ему и дорога.

\\вернул ТСу к нику комментарий, который был ранее.

В malloc-е уже есть защита от переполнения буфера.

как именно реализовано?

В malloc-е уже есть защита от переполнения буфера.

#include <stdlib.h>
#include <stdio.h>

int main(void)
{
        char *a=malloc(4);
        a[4] = 'q';
        a[5] = 'q';
        a[6] = 0;

        printf("%s\n", &(a[4]));

        free(a);
        return 0;
}

что у тебя пишет

В malloc-е уже есть защита от переполнения буфера. OpenSSL предусмотрительно написал workaround, чтобы эта защита не работала

Еще одному Мойша напел Шаляпина.

"...workaround, одним из побочных эффектов которого было выключение защиты malloc в системах, где такая она предусмотрена и работает."

Так лучше?

И что это такая за системы защиты malloc в системах?

А ты не 4 попробуй. Ты хотя бы на 64 килобайта прогуляйся.

http://mdoc.su/o/malloc читать секцию о MALLOC_OPTIONS

И тут до кучи: http://www.drijf.net/malloc/

"...workaround, одним из побочных эффектов которого было выключение защиты malloc в системах, где такая она предусмотрена и работает."

Так лучше?

Нет. Во-первых, по уверениям разрабов OpenSSL, этот workaround обычно отключен; во-вторых, сабжевая уязвимость - это не совсем переполнение буфера, это доступ за границу буфера _на чтение_ - мне неизвестны malloc, которые это блокируют.

Guard page без доступа на чтение может поймать и это.

о, спасибо.

доступ за границу буфера _на чтение_ - мне неизвестны malloc, которые это блокируют

#include <sys/param.h>
#include <assert.h>
#include <stdlib.h>
#include <stdio.h>

int 
main(void)
{
        char *s;

        s = malloc(PAGE_SIZE);
        assert(s);

        printf("%x\n", s[PAGE_SIZE]);

        free(s);

        return 0;
}

$ make m && ./m
cc -O2 -pipe -o m m.c 
Segmentation fault (core dumped)

Guard page без доступа на чтение может поймать и это.

Может. Но AFAIK даже в OpenBSD эта опция по умолчанию отключена, и в любом случае данные от конца блока до начала guard page доступны.

/etc/malloc.conf в студию, а то ты только что доказал неуязвимость OpenBSD к heartbleed.

Нету его, нету. ;) Это per-default.

$ env | grep -c MALLOC_OPTIONS
0
$ stat /etc/malloc.conf
stat: cannot stat `/etc/malloc.conf': No such file or directory

Но был всё равно уязвим, т.к. это работает только на границах страниц, если я ничего не путаю.

Это доступ за границу страницы.

тогда я вывалюсь за пределы страницы и получу segfault. Это с самим malloc никак не связано, а реализовано в менеджере памяти в ядре.

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

cvs-255 ★★★ упорот

Это cvs-255!

И в тоже время OpenBSD это ловит, а Linux вот нет.

UPD: обновил для портабельности:

#include <assert.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int 
main(void)
{
        char *s;
        size_t sz = sysconf(_SC_PAGESIZE);

        s = malloc(sz);
        assert(s);

        printf("%x\n", s[sz]);

        free(s);

        return 0;
}

$ uname -a && make m && ./m 
OpenBSD dim13.org 5.4 GENERIC.MP#41 amd64
cc -O2 -pipe -o m m.c 
Segmentation fault (core dumped)

$ uname -a && make m && ./m
Linux otto 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
cc     m.c   -o m
0

Вот так то.

Нету его, нету. ;) Это per-default.

Даже не знаю, кому из вас верить: http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

Это cvs-255!

ААА ТЫ ЗНАЛ!!11

Это было поведение по умолчанию. Заметь, что я аллоцировал целую страницу (4096 байт), вышел за пределы и уткнулся в guard-page. Но опциями можно повключать гораздо больше и ловить оно будет соответственно больше.

Это было поведение по умолчанию

С какого времени?

Заметь, что я [...]

Спасибо, Капитан.

Не знаю, не скажу. Но факт на лицо.

Ты хочешь сказать, что в linux не ловится доступ к несуществующей странице?

Скорее всего в linux идет несколько страниц подряд, а в openbsd нет, потому в linux и не вываливаешься за пределы доступного адресного пространства.

Кстати, есть мнение, что именно упоротость спорыньей в средние века и привела к началу эпохи возрождения

Скорее всего в linux идет несколько страниц подряд, а в openbsd нет, потому в linux и не вываливаешься за пределы доступного адресного пространства.

Даже если это так — то это уже жирный bug.

если это и bug, то баг архитектуры x86(-64). Так как других способов отловить переполнение, кроме как если оно приведет к вываливанию за пределы доступного адресного пространства процесса, нет.

Эм? Но другие ведь это ловят? Ловят! Дак при чём тут архитектура? Отмазка не засчитанна. На пересдачу. ☺

Они точно также плохо ловят, только когда вываливается за пределы адресного пространства. Оно у них чуть по другому организовано, так что «порог срабатывания» ниже, но нормальной защиты буфера от переполнения там не реализовано и не может быть реализовано, т.к. это должно делаться на уровне MMU, который есть часть процессора.

Может быть, это возможно сделать через команды виртуализации, но это само по себе серьезно усложнит дело

Кстати, я слышал, что в эльбрусах это таки сделали.

Там всё гораздо интересней. Погрепь следующий линк на предмет 'malloc' и 'memory': http://www.openbsd.org/papers/

Таки причём тут SSL? Там собственный аллокатор

С какого времени?

# ./m      
Segmentation fault (core dumped) 
# uname -a 
OpenBSD <censored> 4.6 GENERIC.MP#89 i386
# env | grep MALLOC_OPTIONS
# stat /etc/malloc.conf     
stat: /etc/malloc.conf: No such file or directory

OpenBSD 4.6
Released Oct 18, 2009

Даже еще раньше

# ./m
Segmentation fault (core dumped) 
# uname -a             
OpenBSD <censored> 3.9 GENERIC#617 i386

OpenBSD 3.9
Released May 1, 2006

640 кб хватит всем.