|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Thu, 08 Feb 2007
Addition filesystem feature.
It is quite good to have possibility for administrator
to put some files together (i.e. close to each other on disk),
which will greatly speed up setup, where all them are needed in a short
period of time - like boot up or process startup. It can not be solved
by delayed allocation, since kernel does not know about relations
between files, which in turn results in a need for some kind
of on-line disk layout changer (in ext4 it is known as defragmenter),
which I was against for in my FS design notes.
/devel/fs :: Link / Comments ()
Glibc function pointer encryption.
It was actually committed years ago - at the end of 2005,
but Ulrich Drepper
only announced it quite recently.
Here is bits of presentation:
One of the remaining attack vectors in the runtime are function pointers in writable memory.
Overwrite the value and you can redirect execution. Of course the pointer must actually be
used and randomization must be overcome, but it's theoretically possible.
The remedy I've implemented in libc internally is to encrypt function pointers. I.e., they are not
stored as-is but instead in a mangled form. This mangling consists in my code of XOR-ing the pointer
value with a random 32/64-bit value. Each process has its own random value. The code was publicly
committed back in December 2005 and is in FC6.
What is protected? I hope meanwhile most function pointers in libc. Some are probably still missing
and others cannot be handled this way since they are visible to the outside. For some broken programs
(including UML) the setjmp change was the biggest. These programs tried to access the stored code
address which now is not really useful anymore (program don't know how to decrypt the value).
Other pointers which are encrypted are the iconv and atexit structures as well as some function pointer
tables people don't really know about, they are completely internal.
But let's see, what exactly is implemented? Searching for PTR_MANGLE/PTR_DEMANGLE
macros shows, that only some registers in setjmp() code
and atexit() and iconv related pointers, all of them are stored
in private areas already, and hacker will crack his head just to find, for example,
list of exit functions to change. It is much easier to overwrite GOT for example
or implement other 'return-to-glibc' technique, instead of searching for private function pointers
in the glibc...
And even that encryption is not that complex - pointer is XORed
with value stored in TCB at fixed location from the start, so if attacked can access %gs
register, he knows that secret value.
It is of course a good step, but it does not provide any real security, which is advertised by RedHat.
Likely it was the only reason I started to upgrade FC5 to FC6 - I wanted to check how pointers
are encrypted and tried to determine if it is possible to hack that.
/devel/other :: Link / Comments ()
Hackish way to upgrade FC5 to FC6 using yum on x86_64.
It does not work as described in the web due to problems
in ELF libs dependency. And you can not replace it with --nodeps
flag since rpm stops to work with new utils.
So, what you need, is following steps:
- backup content of the following FC5 rpms:
- elfutils-0.119-1.2.1.x86_64.rpm
- elfutils-libelf-0.119-1.2.1.x86_64.rpm
- elfutils-libs-0.119-1.2.1.x86_64.rpm
By content I mean files and dirs which will be put into /usr dir
when installed (use mc or cpio).
- install following libs from FC6 distro with
--nodeps flag:
- elfutils-0.123-1.fc6.x86_64.rpm
- elfutils-libelf-0.123-1.fc6.x86_64.rpm
- elfutils-libs-0.123-1.fc6.x86_64.rpm
- run
yum update (implied you have installed fedora-release-6* rpms)
- copy content of the elf libs from FC6 and remove old elf libs from FC5
RedHat still lacks good support for x86_64 and again requires some hacks to
uprade using yum.
/devel/other :: Link / Comments ()
|