So back to the start of the thread: the question we are trying to answer is:<br><br>"Why do we care about half-width or full-width encoding or n-squared encoding types if they aren't interpreted/converted/canonicalized properly anyway?!?"
<br><br>From there everyone spread out and dug down into different weeds. But we're talking about different specific issues w/out context.<br><br>Instead of saying you were missing something (Brian) I should instead have asked what context you are speaking of... because there are several here. Encoding type issue(s) contexts:
<br><br>1. What web servers do automatically (decoding)<br>2. What stuff plugged into web servers does automatically (decoding)<br>3. What frameworks do automatically (decoding)<br>4. What developers chose to do with their code, frameworks, web server plugins, and other crazy talk, that results in decoding/canonicalization.
<br><br>Per #4, there's a lot of discussion and theory about this, but in the real world.... Crazy encoding/decoding things exist out there in production Internet-land. They've been there for years and still are, in major applications.
<br><br>I can theorize why some of the crazy things in the wild exist, but in the end they may be simple control-c/v artifacts.<br><br>(As Napoleon said: "Never ascribe to malice what one can ascribe to incompetence.")
<br><br>In my answers, I was referring largely to #4 in the contexts above, also phrased as:<br><br>Crazy Things Developers Do with their Code plus uses of #1-#3 that result in encoded attack vectors, both client and server-side.
<br><br>Not sure what the Cert advisory was tickled by, but there's more viable types than just what they cover. Maybe someone is working on a "new" IDS evasion whitepaper taking Ptacek's ideas and search/replacing "packet fragmentation & target OS reassembly" with "crazy encoding scheme some apps using the HTTP protocol will decode and some parser will execute but most IDS/IPS/Firewalls and mice do not decode and parse properly"
<br><br><br>-- <br>Arian Evans<br>scrutinizing shameless software insecurity<br><br>"Diplomacy is the art of saying "Nice doggie" until you can find a rock." -- Will Rogers
<br><br><br><br><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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 5/21/07, Brian Eaton <<a href="mailto:eaton.lists@gmail.com">eaton.lists@gmail.com</a>> wrote:<br>> 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>To summarize what I've heard from various sources: I am missing<br>something important. =) Both PHP and <a href="http://ASP.NET">ASP.NET</a> will decode these<br>characters into their ASCII equivalents. I don't think J2EE apps are
<br>vulnerable, but this is definitely useful for more more than just<br>homograph attacks.<br><br>Thanks to the various people who have tested this out!<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><br>