Hanno's blog

Update: When I wrote this blog post it was an open question for me whether using Address Sanitizer in production is a good idea. A recent analysis posted on the oss-security mailing list explains in detail why using Asan in its current form is almost certainly not a good idea. Having any suid binary built with Asan enables a local root exploit - and there are various other issues. Therefore using Gentoo with Address Sanitizer is only recommended for developing and debugging purposes.

Address Sanitizer is a remarkable feature that is part of the gcc and clang compilers. It can be used to find many typical C bugs - invalid memory reads and writes, use after free errors etc. - while running applications. It has found countless bugs in many software packages. I'm often surprised that many people in the free software community seem to be unaware of this powerful tool.

Address Sanitizer is mainly intended to be a debugging tool. It is usually used to test single applications, often in combination with fuzzing. But as Address Sanitizer can prevent many typical C security bugs - why not use it in production? It doesn't come for free. Address Sanitizer takes significantly more memory and slows down applications by 50 - 100 %. But for some security sensitive applications this may be a reasonable trade-off. The Tor project is already experimenting with this with its Hardened Tor Browser.

One project I've been working on in the past months is to allow a Gentoo system to be compiled with Address Sanitizer. Today I'm publishing this and want to allow others to test it. I have created a page in the Gentoo Wiki that should become the central documentation hub for this project. I published an overlay with several fixes and quirks on Github.

I see this work as part of my Fuzzing Project. (I'm posting it here because the Gentoo category of my personal blog gets indexed by Planet Gentoo.)

I am not sure if using Gentoo with Address Sanitizer is reasonable for a production system. One thing that makes me uneasy in suggesting this for high security requirements is that it's currently incompatible with Grsecurity. But just creating this project already caused me to find a whole number of bugs in several applications. Some notable examples include Coreutils/shred, Bash ([2], [3]), man-db, Pidgin-OTR, Courier, Syslog-NG, Screen, Claws-Mail ([2], [3]), ProFTPD ([2], [3]) ICU, TCL ([2]), Dovecot. I think it was worth the effort.

I will present this work in a talk at FOSDEM in Brussels this Saturday, 14:00, in the Security Devroom.

Okay, I knew PHP isn't the most well-designed language in the world. I knew it grew up from a hobbyist language and that it is used for things today it never was meant for. I knew that it's function names sometimes aren't very intuitive.
But today I started to hate it. Now, beside various other strange things, this one let's me wonder which drugs the person that implemented this was consuming:

PHP is, by design, syntactical similar to C, meaning it has curly brackets, same comment syntax, same syntax for if, for and other basic commands. Now, one would probably think that a function named the same in C and PHP would do the same. Or at least something similar.
Due to the fact that C is very low-level, it has a function called sizeof() that gives you the amount of bytes a variable type uses in memory. E. g., an integer is the basic type of the current architecture, not always the same size (4 byte on i386, 8 byte on amd64). With sizeof() you can get the size of the type.
Now, I was looking for a function to get the number of elements in an array. I searched and found, well, sizeof(). Which I couldn't really believe. Due to the abstract structure of PHP, it seemed quite impossible to me to have something like sizeof() in php. It really gives you the number of elements in an array.