secure programming (was: [PATCH] users: new applet)

[Matthias Andree]

Am 27.07.2011 15:26, schrieb gotrunks at gmail.com:
> On Wed, Jul 27, 2011 at 3:23 PM, Matthias Andree <mandree at freebsd.org> wrote:
>> Am 27.07.2011 13:19, schrieb gotrunks at gmail.com:
>>
>>> It was about saving bytes but ok, revised patch attached.
>>
>> Trading a dozen bytes for security is unacceptable.
>>
>>
> 
> I'm sorry, I didn't see a security fault here.

Then let me show you:  You have user names contain that contain % with
valid format specifiers, you lose.  I've seen such things happen in the
wild, in so-called security software.

Considering some vendor might want to put daemon users in a separate
name space and prefix them like that, it's not as unreal as you may assume.

Considering someone similarly unaware of security problems might not
validate web input properly and "inherit" such characters through a web
interface for user management, where " \ % * ; and ' are interesting
characters to inject.

Life of the bug:

- because printf() then expects further arguments, printf() then reads
random garbage from the stack if it finds %...s, %...f and similar, and
dereferences it, which either yields further garbage printed out (less
severe), or in the worst case, with properly prepared stack, yields a
remote root.


Dangers:

- not readily found in testing

- non-obvious

- security relevant

- not easily fixed in embedded devices that got deployed, hence costly


Remedy:

- control your format strings. String literals are safer because the
compiler can check arguments.  Recent GCC, Intel C++ and Clang versions
do check if you request that.  I've not used others in a long time.

- I suggest gcc -Werror -Wformat=2 to reveal such holes.


Further reading:

http://en.wikipedia.org/wiki/Uncontrolled_format_string
http://www.tech-faq.com/format-string-vulnerability.html
http://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf
http://julianor.tripod.com/bc/tn-usfs.pdf


Note: tweaking bytes in a high-level language is useless. You don't know
what optimization possibilities exist under the hood for the compiler,
they are machine dependent, and that's especially important for busybox
which runs on all sorts of devices from ARM to Zilog (possibly, didn't
check the latter ;-))