full-disclosure-uk May 2007 archive
Main Archive Page > Month Archives  > full-disclosure-uk archives
full-disclosure-uk: Re: [Full-disclosure] [WEB SECURITY] Re: noi

Re: [Full-disclosure] [WEB SECURITY] Re: noise about full-width encoding bypass?

From: Arian J. Evans <arian.evans_at_nospam>
Date: Mon May 21 2007 - 21:10:46 GMT
To: "Brian Eaton" <eaton.lists@gmail.com>, "Web Security" <websecurity@webappsec.org>, Full-Disclosure <full-disclosure@lists.grok.org.uk>

So back to the start of the thread: the question we are trying to answer is:

"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?!?"

>From there everyone spread out and dug down into different weeds. But we're
talking about different specific issues w/out context.

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:

  1. What web servers do automatically (decoding)
  2. What stuff plugged into web servers does automatically (decoding)
  3. What frameworks do automatically (decoding)
  4. What developers chose to do with their code, frameworks, web server plugins, and other crazy talk, that results in decoding/canonicalization.

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.

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.

(As Napoleon said: "Never ascribe to malice what one can ascribe to incompetence.")

In my answers, I was referring largely to #4 in the contexts above, also phrased as:

Crazy Things Developers Do with their Code plus uses of #1-#3 that result in encoded attack vectors, both client and server-side.

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" -- Arian Evans scrutinizing shameless software insecurity "Diplomacy is the art of saying "Nice doggie" until you can find a rock." -- Will Rogers On 5/21/07, Brian Eaton <eaton.lists@gmail.com> wrote:
> On 5/21/07, Brian Eaton <eaton.lists@gmail.com> wrote:
> > 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.
> To summarize what I've heard from various sources: I am missing
> something important. =) Both PHP and ASP.NET will decode these
> characters into their ASCII equivalents. I don't think J2EE apps are
> vulnerable, but this is definitely useful for more more than just
> homograph attacks.
> Thanks to the various people who have tested this out!
> Regards,
> Brian
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/