full-disclosure - Re: noise about full-width encoding bypass?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Mon, 21 May 2007 17:00:56 +0200
From: "Łukasz Pilorz" <lukasz@...orz.net>
To: eaton.lists@...il.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: noise about full-width encoding bypass?

Hi,
I think this encoding bypass may have some impact on applications
which convert data from Unicode/UTF to other encodings. A naive
example:
http://lukasz.pilorz.net/testy/full_width_utf/index.phps

But I don't suggest this was the main problem, I have probably missed
something too.
Best regards,
Łukasz Pilorz

Brian Eaton napisał(a):
> Has anyone had a look at the full-width unicode encoding trick discussed here?
>
> http://www.kb.cert.org/vuls/id/739224
>
> AFAICT, this technique could be useful for a homograph attack.  I
> don't think it's useful for much else.  However, a few vendors have
> reacted already, so I may be missing something important.
>
> Here's why I think the attack is mostly harmless:
>
> Let's say an attacker wants to use this technique to hide a SQL
> injection attack.  They decide to use a full-width encoding for single
> quote, 0xff 0x07.  They successfully bypass the IDS, because the IDS
> is only scanning for normal single quotes.  (You can see the encodings
> and their graphical representation here:
> http://www.unicode.org/charts/PDF/UFF00.pdf)
>
> If the SQL engine is processing queries in Unicode, then 0xff 0x07
> will be treated as a normal unicode character, not a single quote.
> The sequence 0xff 0x07 is not equivalent to 0x27, the real single
> quote value.  No SQL injection occurs.
>
> If the SQL engine is processing queries in UTF-8, then 0xff 0x07 will
> be converted from Unicode to UTF-8: 0xef 0xbc 0x87.  Again, the engine
> does not recognize 0xef 0xbc 0x87 as equivalent to 0x27.
>
> If the SQL engine is processing queries in ASCII or ISO-8859-1, the
> conversion from unicode to the code page used by the engine will fail.
>  Either the engine will give up on the query, or it might substitute a
> question mark (?) for the unconvertible character.
>
> To summarize: I think half-width and full-width unicode characters are
> characters that happen to have the same graphical representation as
> other characters, but don't carry any special significance outside of
> that graphical representation.  The graphical representation can be
> important in homograph attacks, but otherwise I don't see this
> technique as particularly useful to an attacker.
>
> Any comments on what I may have missed?
>
> Regards,
> Brian
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/