В Kerberos найдены опасные уязвимости

Исходное сообщение об уязвимости: http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2006-003-mechglue.txt

Патч: http://web.mit.edu/kerberos/advisories/2006-003-patch.txt

Ещё одна уязвимость в Kerberos: http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2006-002-rpc.txt

Патч: http://web.mit.edu/kerberos/advisories/2006-002-patch.txt

Откуда взялась ошибка в _протоколе_? В исходной новости говорится об неинициалищированных указателях в реализации kadmind от MIT. Во-первых kadmind не существенен для нормальной работы (администратор может работать через локальную версию на "запечатанном" сервере) или пользоваться реализацией от heimdal (про нее в новости ничего не говорится).

Это же cnews.ru. По-моему, новости у них можно прочитать только затем, чтобы потом поискать первоначальный или близкий к нему источник.

Кстати, исправил текст новости.

> новости у них можно прочитать только затем, чтобы потом поискать первоначальный или близкий к нему источник.

учту, thnx :)

очередная собачья чушь

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

Не проинициализированные указатели могут получить значения, зависящие от злоумышленника. И потом если по такому указателю перейти...

Допустим, вызывалась функция A(), в ней использовался буффер в стеке. Буффер хранил данные от злоумышленника. По возврате из A() вызвали B(), в ней локальные переменные получат значения из буффера функции A().

Всё ИМХО и не относится к этой уязвимости

1)ээээ, батенька, еще не факт, что вобще каким-то образом в стеке окажутся значения, полученные от злоумышленника.
2)не факт что переменные Б получат мусор от А. Т.к. эти самые указатели в кадре вызова Б могут не находится на том самом месте, где были данные от злоумышленника в локальной переменной ф-ии А.
3) вообще данные от злоумышленника могут НЕ находится в кадре никогда. память под них может быть выделена особо. И так обычно делают умные программисты на всякий случай.
4) указатели могут быть не проинициализированны по причине инициализации их в той условной ветви, где ими действительно пользуются. например, это может выглядеть так:
int fn(int a){
char *arr;
int b;
if(a){
b=a+1; //или еще что нибудь подлиннее :)
return b;
}
arr=getbuf();
b=getindex();
return *((int*)arr+b);
}
так вот, на текст в вышеприведенном стиле обычно больше всего и ругаются. В нем указатель инициализируется только при непосредственной надобности, и никакой дыры нет.

Так что, без реального эксплоита, или, хотя бы, куска листинга и структуры кадра в стеке, такое заявление -- лишь замечание о том, что человеку не нравится стиль кодинга.

А как обстоят дела с безопасностью в Heimdal реализации?