<div>1. You are missing what I consider to be the major point.</div>
<div> </div>
<div>2. I don't know the context of the cert advisory; there are more encoding types than full under full-width that IDS today don't decode (that are of interest to us as well), but...</div>
<div> </div>
<div>3. The question we need to ask ourselves is one of cannonicalization. In monolithic J2EE projects and modern cobbled-together web code, PHP is notoriously dirty for this, there are *multiple* layers of cannonicalization that often occur specific to particular untrusted entry points. This stuff is really hard to find (initially) in source code.
</div>
<div> </div>
<div>You will find that sometimes you can even double-encode your attacks, and they get decoded/cannonicalized to their common ASCII or UTF-8 (or whatever format) before they read the parser (query engine, browser, shell script, smtp relay, whatever parser you are targeting).
</div>
<div> </div>
<div>It's fair to be skeptical about this though Brian. It's not common to find where these attacks work, and I find that few people go beyond buzzwords and encoding-attack-technobafflegab when discussing this subject in the security "consultant" space.
</div>
<div> </div>
<div>Guess it's finally time for a paper on this,</div>
<div> </div>
<div>-- <br>Arian Evans<br>solipsistic software security sophist<br><br>"I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams <br> </div>
<div><span class="gmail_quote">On 5/21/07, <b class="gmail_sendername">Brian Eaton</b> <<a href="mailto:eaton.lists@gmail.com">eaton.lists@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Has anyone had a look at the full-width unicode encoding trick discussed here?<br><br><a href="http://www.kb.cert.org/vuls/id/739224">
http://www.kb.cert.org/vuls/id/739224</a><br><br>AFAICT, this technique could be useful for a homograph attack. I<br>don't think it's useful for much else. However, a few vendors have<br>reacted already, so I may be missing something important.
<br><br>Here's why I think the attack is mostly harmless:<br><br>Let's say an attacker wants to use this technique to hide a SQL<br>injection attack. They decide to use a full-width encoding for single<br>quote, 0xff 0x07. They successfully bypass the IDS, because the IDS
<br>is only scanning for normal single quotes. (You can see the encodings<br>and their graphical representation here:<br><a href="http://www.unicode.org/charts/PDF/UFF00.pdf">http://www.unicode.org/charts/PDF/UFF00.pdf</a>
)<br><br>If the SQL engine is processing queries in Unicode, then 0xff 0x07<br>will be treated as a normal unicode character, not a single quote.<br>The sequence 0xff 0x07 is not equivalent to 0x27, the real single<br>quote value. No SQL injection occurs.
<br><br>If the SQL engine is processing queries in UTF-8, then 0xff 0x07 will<br>be converted from Unicode to UTF-8: 0xef 0xbc 0x87. Again, the engine<br>does not recognize 0xef 0xbc 0x87 as equivalent to 0x27.<br><br>If the SQL engine is processing queries in ASCII or ISO-8859-1, the
<br>conversion from unicode to the code page used by the engine will fail.<br>Either the engine will give up on the query, or it might substitute a<br>question mark (?) for the unconvertible character.<br><br>To summarize: I think half-width and full-width unicode characters are
<br>characters that happen to have the same graphical representation as<br>other characters, but don't carry any special significance outside of<br>that graphical representation. The graphical representation can be<br>
important in homograph attacks, but otherwise I don't see this<br>technique as particularly useful to an attacker.<br><br>Any comments on what I may have missed?<br><br>Regards,<br>Brian<br><br>----------------------------------------------------------------------------
<br>Join us on IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #webappsec<br><br>Have a question? Search The Web Security Mailing List Archives:<br><a href="http://www.webappsec.org/lists/websecurity/">http://www.webappsec.org/lists/websecurity/
</a><br><br>Subscribe via RSS:<br><a href="http://www.webappsec.org/rss/websecurity.rss">http://www.webappsec.org/rss/websecurity.rss</a> [RSS Feed]<br></blockquote></div><br><br clear="all"><br>