Not logged in. · Lost password · Register
Forum: Support Bug reports and troubleshooting RSS
\0 bug
Page:  1  2  3  next 
Avatar
Reply · Quote Saxtus #1
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
Subject: \0 bug
I suppose the \0 bug is fixed in this version but I don't want to mention what happens when I am going to search for that...
Can you patch it because someone might exploit it?
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Yves (Administrator) #2
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
The \0 character is filtered out of any user input that UNB receives from the browser. Can you please be more specific about your concern?
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #3
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
It seems that pre-20070420-dev \0 was filtered (haven't tested 20070420-dev yet). In this board version (20070420-dev) I can write it correctly so I think it was fixed.
But if someone search for \0 will get an extremely high amount of results. Doesn't this abuse CPU and/or memory?
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Yves (Administrator) #4
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
Do you mean the literal "\0" or the character with the value of zero (0x00)? I see that searching for the literal "\0" matches a whole lot of posts that don't containt that text. I'm currently looking for the cause. What I meant about filtering applies to the single character 0x00 which is known to cause some trouble with diverse PHP functions. Since it cannot be entered with a keyboard anyway, it's simply dropped at the entry check. This is included for a long time now.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #5
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
The literal \0
If I try to type the above to my board version I will get:
The literal

Same apply to create empty subjects :)
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Yves (Administrator) #6
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
It seems like MySQL's LIKE operator gets entirely confused when fed with \ (backslash) characters in general. I see that my string quoting function works as expected, but the database results just don't match the SQL query.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #7
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
I have PHP v4.3.2 but take a look at this, might help a bit to pinpoint where the problem lies...
addslashes() Vulnerability:

Scope:
PHP version 4.3.9 contains a bug in the function addslashes().
addslashes() can be used to sanitize userinput and render it thus
impossible for an attacker to influence scripts by injection meta
characters. In the default configuration, magic_quotes_gpc is set to "On"
which automagically performs addslashes() on every input value. However
because of a bug, the NULL byte is not correctly encoded by addslashes,
enabling an attacker to read arbitrary files from the file system, if user
input is used within include() or require() directives.

Details:
Addslashes should turn a NULL byte (will be written as %00 in this
advisory) into the string "\0" (backslash zero). In version 4.3.9 the
NULL byte is encoded as "\%00" (backslash null byte). Everything after
the NULL byte is ignored in include and require directives so that an
attacker can truncate the name of the file that is included in the PHP
script. The last character however will always be the backslash. As in
Windows the backslash is the path delimitor, this does not matter - the
file named before the backslash is still loaded.
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Yves (Administrator) #8
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I don't use addslashes, its counterpart and work around any of PHP's ways to insert backslashes and other crap into user input. I can handle those characters, I know where they need to be escaped and where it's a bad idea. So this can't be the cause.

I'm currently debugging SQL queries in general and it seems that in MySQL SQL, strings for the LIKE operator need to be escaped twice. Not sure why, I'm currently studying the documentation. If you search for "\", it actually looks for anything that ends with "%". If you look for "\\", it actually looks for "\". "\\\\" will look for "\\".
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #9
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
You've changed something between 20070327-dev (my installed version) and 20070420-dev (this board's version) that might explain why \0 doesn't show on my board (they lost even after previewing a post)?
The Answer to Life, the Universe, and Everything = 42
This post was edited on 2007-05-23, 14:43 by Saxtus.
Avatar
Reply · Quote Yves (Administrator) #10
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I wouldn't know.

Here's my current findings:

mysql> select 'abc\\def';
+---------+
| abc\def |
+---------+
| abc\def |
+---------+
1 row in set (0.00 sec)

mysql> select 'abc\\def' like '%\\%';
+------------------------+
| 'abc\\def' like '%\\%' |
+------------------------+
|                      0 |
+------------------------+
1 row in set (0.00 sec)

mysql> select 'abc\\def' like '%\\\\%';
+--------------------------+
| 'abc\\def' like '%\\\\%' |
+--------------------------+
|                        1 |
+--------------------------+
1 row in set (0.00 sec)


This sounds to me like a bug in MySQL. I'm going to ask on the mysql mailing list. This may take a while.
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #11
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
Damn, I am gonna do what I was hopping to skip: Install 20070420-dev to my server too.
I will let you know my findings too...
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Saxtus #12
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
Done with the update to 20070420-dev.
Unfortunately it is still happening to me.
So it must be either my PHP v4.3.2 or MySQL v3.23.58
It happened during preview post too, so I think it isn't MySQL related.
At any case I am screwed.
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Saxtus #13
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
Forgot to mention that at my board the \0 search return 0 results.
The Answer to Life, the Universe, and Everything = 42
Avatar
Reply · Quote Yves (Administrator) #14
User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members
Show profile · Link to this post
I further investigated the problem that "\0" is disappearing from user input, which doesn't seem to be related to the wrong search results when using "\" in search terms.

If PHP's option magic_quotes_gpc is turned on, then \ ' and " characters are prefixed with another \. So \ is becoming \\. I'm reversing that in UNB. But the PHP manual also says that the NUL character (0x00) is converted to \0 or something, it's not very clear there. The problem is that I can't see an easy way to reverse that and drop that character without interfering with the other conversions. So if you have the choice, then disable all PHP options that contain "magic" and "quote" in them. This will work around our battle of string translating that PHP seems to have won for now (which is not good).
♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬
Avatar
Reply · Quote Saxtus #15
Member since Jan 2007 · 84 posts · Location: Athens, Greece
Group memberships: Members
Show profile · Link to this post
Adding (without even restarting apache!) this:
php_value magic_quotes_gpc off
after the last line of your .htaccess file solved my problem!

Now I have the search for \0 problem too! Yay! :-p
The Answer to Life, the Universe, and Everything = 42
Close Smaller – Larger + Reply to this post:
Verification code: VeriCode Please note the verification code from the picture into the text field next to it.
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Special characters:
Page:  1  2  3  next 
Go to forum
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Page created in 372 ms (328 ms) · 132 database queries in 256 ms
Current time: 2010-07-30, 10:52:31 (UTC +02:00)