Slashdot Mirror
Unicode Encoding Flaw Widespread
LordNikon writes "According to this CERT advisory: 'Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system.' A proof of concept affecting IIS is already being posted to security mailing lists. Cisco IPS and other IDS products are also affected." The CERT advisory lists 93 systems, with 6 reported as vulnerable (including 3com, Cisco, and Snort), 5 known not vulnerable (including Apple and HP), and the rest unknown.
That Unicode is a very bad idea in all semantics carrying containers is nothing new. In fact one of the counterarguments to Unicode ist that it is a nightmare to secure. Filter evasion was expected to be a typical security concern. We will see more of this and all only because some people want features without ever reflecting on what problems they might cause.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
To think that even English fits in 7-bit ASCII is naïve.
It is a vulnerability, in the strict sense.
...
It is a self-inflicted misbehaviour as in common sense.
It is like those silly Cisco content inspectors on port 25, that try to avoid attacks on flimsy MTAs.
It is like someone dying from a jab against measles: the jab protected that person from contracting measles, actually.
It is like those stupid anti-virus programs that are more vulnerable than the daemons they profess to protect.
When the attacker uses a codepage different from the one that you think she ought to use, she can circumvent your content filter. Which ought not be an attack vector, in any case.
As I said: nothing to see, move along
At any rate, running in a chroot jail is arguably better in some ways than just running as an unprivileged user. Vista has some sandboxing features, using 'integrity levels' and redirecting various file and registry accesses to a 'virtual store', but I'm not really familiar with them, except for the basics, and I don't know if IIS uses them anyway.
I think you've missed his point. There are now two ways that, for example, a quote character can be passed as user input to your program: either as " or as %ublah.
Your program, sitting below the layer performing the unicode translations, doesn't need to do anything differently from before, as it doesn't matter which of the two methods were used. If you _relied on_ the layers above you to strip out, reject, escape, or whatever, quote characters, then you're writing teabag code, and should get a job selling flowers instead, as software engineering is beyond you.
Always validate user input to your own specification. Never rely on something external to do it.
This exploit hasn't changed the rules one little bit, it's just highlighted the fact that some idiots don't follow them.
Also FatPhil on SoylentNews, id 863
Is this another problem with unescaped quotes? When will people learn? Not an hour goes by that a system doesn't get attacked by SQL injection attacks. Why do programmers continue to not use things like prepared statements which are invulnerable against such attacks. I blame it on the people writing the tutorials. Every beginner tutorial on the web shows queries being constructed at runtime, and doesn't have any mention of how insecure doing things like this is. It's hard to break the habit once you've been programming like that for so long.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Well, the way I see it, there are three ways to handle Unicode characters (one of which is wrong): store as full two-byte Unicode values (inefficient when using mostly ASCII characters like in english), store in a UTF character set such as UTF-8 (useful for primarily ASCII text as it is a superset of ASCII), or pretend it isn't Unicode and treat it as two (or three if input is in UTF-8 for example) separate ASCII characters (bad).
So, perhaps if data was all stored and represented in UTF-8, for example, this wouldn't be a problem? Or perhaps stored as raw Unicode characters via wchar_t (or language equivalent like u"" in Python)?
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
1) You escape a Unicode string that contains fullwidth characters. The fullwidth characters have no special properties, so they aren't escaped.
2) You translate the escaped Unicode string into ASCII. Fullwidth characters are translated into halfwidth characters. Some of those halfwidth characters, like quotes, have special properties.
The fullwidth quote was perfectly safe, because it wasn't treated like a quote. It was treated the same as an "A" or "b". But when it was translated to a "normal" quote, it went from being a plain old character to being a quote character, with a completely different meaning.
The lesson here is that you should never translate fullwidth characters into halfwidth characters unless you know whether they should be escaped or not, and you should escape them during translation if they need to be. Also, it's not a good idea to translate an escaped string between character sets.