Re: [gentoo-user-ru] article about Hardened Gentoo

[Vladimir Solomatin <slash@relex.ru>]

Hello, Alex Efros
On 11/14/2005 04:39 PM, you wrote:
> Executable anonymous mapping             : Killed
> Executable bss                           : Killed
> Executable data                          : Killed
> Executable heap                          : Killed
> Executable stack                         : Killed
> Executable anonymous mapping (mprotect)  : Killed
> Executable bss (mprotect)                : Killed
> Executable data (mprotect)               : Killed
> Executable heap (mprotect)               : Killed
> Executable stack (mprotect)              : Killed
> Executable shared library bss (mprotect) : Killed
> Executable shared library data (mprotect): Killed
> Writable text segments                   : Killed
> Anonymous mapping randomisation test     : 15 bits (guessed)
> Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
> Heap randomisation test (ET_DYN)         : 23 bits (guessed)
> Main executable randomisation (ET_EXEC)  : No randomisation
> Main executable randomisation (ET_DYN)   : 15 bits (guessed)
> Shared library randomisation test        : 15 bits (guessed)
> Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
> Stack randomisation test (PAGEEXEC)      : 24 bits (guessed)
> Return to function (strcpy)              : Vulnerable
> Return to function (memcpy)              : Vulnerable
> Return to function (strcpy, RANDEXEC)    : Vulnerable
> Return to function (memcpy, RANDEXEC)    : Vulnerable
> Executable shared library bss            : Killed
> Executable shared library data           : Killed
>
> Что нужно ещё включить чтобы "Return to function" тоже были защищены я пока
> не разбирался - времени нет.
>   
$ bzless /usr/share/doc/paxtest-0.9.6/README.bz2

Return to function (strcpy)
Return to function (strcpy, RANDEXEC)
Return to function (memcpy)
Return to function (memcpy, RANDEXEC)

        Return to function attacks are very nasty. These tests are hard to
        stop by kernel patches, but they show that there you should not 
expect
        perfect protection from this kind of security patches.

-- 
Vladimir Solomatin (slash@relex.ru)
Phone: + 7 (4732) 711711
Relex Inc, Voronezh.



-- 
Vladimir Solomatin (slash@relex.ru)
Phone: + 7 (4732) 711711
Relex Inc, Voronezh.