Just got pissed with man pages. The idiotic tool has been pissing me off with a complete inability to scroll to the top or wrap around searches to the top. So I did some digging on how man actually displays the data. Here's a inside view on how the gzipped man pages are displayed on screen and it's an excellent example of the unix way of doing things.

bash$ ps x | grep "/usr/share/man"
....    sh -c (cd /usr/share/man && 
		(echo ".pl 1100i"; /usr/bin/gunzip -c '/usr/share/man/man1/seq.1.gz'; 
		echo ".\\\""; echo ".pl \n(nlu+10") | /usr/bin/gtbl |
		nroff --legacy ISO-8859-1 -man -rLL=77n -rLT=77n 2>/dev/null | 
		/usr/bin/less -iRs)

The man page for man provide yet another peice of the puzzle, where exactly this particular command is pulled from. There's a file called /etc/man.config which specifies where the pager (i.e less, more) command is pulled out of. And the default value was less. Instead of replacing it for the entire system, every user can override it by setting $MANPAGER in their environment. And so I did.

export MANPAGER="col -b | vim -R -c 'set ft=man nomod nolist' -"

Now, everytime I type "man something" I can read the manpage in vim.

posted at: 20:44 | path: /hacks | permalink | Tags: public, hacks, vi

I don't know if you are even aware of Chris Shiflett's latest injection bug. It was reported in Mysql 5.0 and suddenly every other DB engine writer realized that it was present in almost every one of those. Postgres even churned out an immediate release to fix this particular issue. The blind spot of the whole fiasco has been multibyte encodings whereas the add_slashes is not binary safe. I was lurking in one of the php developer channels listening to exactly how this could've been exploited and it sounded really serious.

So 0x955c is a single SJIS character, when locale is taken into account, it's just a single character. But when you ignore locale and treat it as latin-1 it looks like 0x95 followed by a backslash. So in the php land, instead of treating it as a single character, escapes the backslash giving you a two character string that looks like 0x955c \ . Now you've got a stray slash which can be used as part of a user supplied escape sequence to inject whatever you require into the query data.

After Sara had explained all that, we turned to the quick fixes. Now, let me introduce UTF-8. A closer inspection of the UTF-8 code table and rationale behind contains the following pearl of wisdom - "The remaining bytes in a multi-byte sequence have 10 as their two most significant bits". So if you were using UTF-8 everywhere to handle unicode, it is not possible for a multi-byte character to end with the ordinal value of \ (0x5c). So convert a string to UTF-8 before escaping the backslashes and you're safe from this bug. So practise safe hex and always use UTF-8.

But for me the whole bug had a more hilarious side to it. Yesterday, I got two php server admins to take down talks.php.net (cached). And the reason it was taken down was due to a set of security vulnerabilities in a set of examples attached to a presentation. Authored by, you guessed it, Chris Shiflett.

<g0pz>    Derick: but I want to know what exactly is bugging the system
<Derick>  the apache process don't want to die either
<Derick>  all are dead now
<Derick>  let's start again
<g0pz>    it was probably the one I had attached with gdb
<Derick>  atleast the site works again
<g0pz>    Derick: shall I kill it again ? :)
<Derick>  g0pz: you know how to?

<g0pz>    edink: http://talks.php.net/presentations/slides/shiflett/
<>        oscon2004/php-security/code/shared-filesystem.php?file=/etc/passwd
<g0pz>    I found this in the access_log !!!
<g0pz>    Derick: that script is very very scary
<g0pz>    *please* *please* take it offline ?

<edink>   bloody hell
<Derick>  i now wiped all *.php files in shiff's dir
<edink>   and he now works for omniti?
<Derick>  yeah :)
<g0pz>    well, I'd have just put a .htaccess Deny all there
<edink>   g0pz: rm -rf is more effenctive :)
<g0pz>    more permanent ? :)
<johann__>slides/acc_php/tmp_table.php - sql (union) injection
<edink>   g0pz: yeah, security risks like that need to be dealt with permanently
<g0pz>    edink: IMHO, he probably wrote up that demo during the lunch break 
<>        before his presentation
<edink>   but how did that bring the site down?
<Derick>  some loop i think
<Derick>  .htaccess is disabled
*   Sebastian .oO( And he is an security expert, right? )
<Derick>  i don't have the time to deal with this either
<edink>   yeah ;)
<Derick>  i'll just turn off talks for now so that somebody can fix it

Somehow it stuck me as ironic that a security expert's own code should help someone read out the /etc/passwd from a publically visible, high traffic server. As Bart Simpson put it - The ironing is delicious.

posted at: 03:22 | path: /php | permalink | Tags: public, hacks, unicode