Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postel’s Principle is a Bad Idea

programmingisterrible.com

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Postel’s Principle is a Bad Idea

#21

Post by MichaelGG »

colomon wrote: post #9

It seems to me it is a very valid principle in many areas. For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do…

Possible attack: Because the strings are not ASCII, implementations now need to bring another library in to decode those strings. Now lets say someone encodes an end-string char (single quote?) using some alternative encoding that doesn't use the ASCII quote char.

When an implementation saves this file, it normalizes that other encoding to use an ASCII single quote, then proceeds to write out the rest of the string. This isn't caught inside the implementation, because the encoding library only normalizes when writing. When it reads the data in, it still just represented it as bytes, and there was no ASCII single quote byte until the end of the dangerous string.

So, yes, it's possible that even something as simple as "string encoding" could be used to implement an attack.

Re: Postel’s Principle is a Bad Idea

#22

Post by pornel »

colomon wrote: post #9

It seems to me it is a very valid principle in many areas. For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do…

That's exactly the kind of security risk that the article is talking about. Internet Explorer could be tricked to use US-ASCII encoding and interpret ¼script¾ as a script tag (CVE 2006-3227)

Liberal vs strict is a false dichotomy. The third solution is to accept all possible inputs, but in a specified way.

Instead of taking draconian XML approach you can solve the problem by taking HTML5 approach and make error handling as interoperable as handling of correct input. In case of STEP files you could require all implementations to clear the 8th bit (or drop or clamp bytes out of range — whatever as long as it's specified and mandatory).

Re: Postel’s Principle is a Bad Idea

#23

Post by colomon »

MichaelGG wrote: post #21
colomon wrote: post #9

It seems to me it is a very valid principle in many areas. For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do…

Possible attack: Because the strings are not ASCII, implementations now need to bring another library in to decode those strings. Now lets say someone encodes an end-string char (single quote?) using some alternative encoding that doesn't use the ASCII quote char. When an implementation saves this file, it normalizes that other encoding to use an ASCII single quote, then proceeds to write out the rest of the string.…

But this is where "be conservative in what you do" comes into play. The STEP format has formal rules for exporting all ASCII, Unicode, and ISO-8859 characters. A well-written STEP string exporter should handle them all without difficulty, no matter what goofy things are in the string.

And again, if you're worried that there may be an attack vector, change high-bit-set characters to "[Illegal character value N]". Though it might be more merciful to assume they just wanted ISO-8859-1 characters and substitute the appropriate control code.

Re: Postel’s Principle is a Bad Idea

#25

Post by colomon »

pornel wrote: post #22
colomon wrote: post #9

It seems to me it is a very valid principle in many areas. For instance, the STEP file standard very clearly states that all input files must be 7-bit ASCII. Many of the programs that generate these files (including earlier versions of my own) paid no attention to this and wrote out 8-bit values in strings if the user requested it. Clearly this behavior is wrong. (The principle agrees: "Be conservative in what you do…

That's exactly the kind of security risk that the article is talking about. Internet Explorer could be tricked to use US-ASCII encoding and interpret ¼script¾ as a script tag (CVE 2006-3227) Liberal vs strict is a false dichotomy. The third solution is to accept all possible inputs, but in a specified way. Instead of taking draconian XML approach you can solve the problem by taking HTML5 approach and make error handl…

Maybe I'm missing something here, but a valid STEP string can already encode any arbitrary Unicode code point. It just does it using 7-bit ASCII. If your code is somehow executing these strings without examining their content, then you are already in big, big trouble.

Trying to do something with 8-bit characters -- whether skipping them, indicating an illegal character in the string, or trying to guess what was really meant -- cannot make that situation any worse.

Re: Postel’s Principle is a Bad Idea

#26

Post by barrkel »

MichaelGG wrote: post #20
mmahemoff wrote: post #18

Browser tolerance for HTML errors is one of the main reasons the web took off so fast.

Citation needed? Is there any reason to believe that if the browsers had insisted on wellformed documented and provided errors like "error at line X, table tag not closed" that people would not have been able to fixup documents? I don't believe that's would have stopped things. But that exact behaviour, trying to infer intent, meant that tons of unspecified behaviour had to be added to all browsers to try to mimic wh…

A nontechnical user, given a choice between two environments, one of which nags them pedantically over technical details, and another which displays the gist of entered content but perhaps with sometimes screwy formatting which one would win?

Word processors won out over text processors for the nontechnical user partially for this reason.

Postel's law applied to HTML let nontechnical users get things done with less impedance. It's less important now not because it was the wrong choice, but because users have moved higher up the stack to CMSes that handle formatting etc.

Consistency across browsers back then was only ever of serious concern to professionals in design or browser programming.

Re: Postel’s Principle is a Bad Idea

#27

Post by btilly »

MichaelGG wrote: post #14

The authors of the SIP spec published another spec (RFC4475[1]) called "SIP torture tests", where they seem to take a perverse glee in showing how messed up their "human readable" syntax can get. They even use the phrase "infer" in several places, encouraging systems to take obviously malformed packets and try to figure out what they meant. Being liberal in accepting input, apart from security issues, seems to create…

I can't read this comment without thinking about SOAP.

Re: Postel’s Principle is a Bad Idea

#29

Post by tedunangst »

colomon wrote: post #25
pornel wrote: post #22

Earlier quoted context omitted.

That's exactly the kind of security risk that the article is talking about. Internet Explorer could be tricked to use US-ASCII encoding and interpret ¼script¾ as a script tag (CVE 2006-3227) Liberal vs strict is a false dichotomy. The third solution is to accept all possible inputs, but in a specified way. Instead of taking draconian XML approach you can solve the problem by taking HTML5 approach and make error handl…

Maybe I'm missing something here, but a valid STEP string can already encode any arbitrary Unicode code point. It just does it using 7-bit ASCII. If your code is somehow executing these strings without examining their content, then you are already in big, big trouble. Trying to do something with 8-bit characters -- whether skipping them, indicating an illegal character in the string, or trying to guess what was reall…

The problem is if you decode a particular byte sequence that causes a bad action (if that's possible with step files) in a different way than some other program that is supposed to keep you safe.

In the case of ie, ie decoded one way and forum software might decode a different way. So the forum software says the string is safe for the browser (according to its decoding rules) but then the browser applies different rules and gets a bad string.

You may not be seeing the danger because you implicitly think a step file from unsafe sources is always unsafe. But imagine if you had a safe file detector program, except it applied different rules than the program you're actually going to open the file with.

Re: Postel’s Principle is a Bad Idea

#30

Post by akkartik »

gruseom wrote: post #3
tptacek wrote: post #2

Postel's Principle was very important for bootstrapping adoption of TCP/IP, but it's mostly a curse in mature systems. It doesn't even help new implementors; instead, it deceives them into thinking that they've achieved interoperability when instead they've accidentally built dependencies on other people's implementation details. That said, I wouldn't suggest that our Insertion, Evasion paper presented an argument re…

when instead they've accidentally built dependencies on other people's implementation details I think it would be very interesting if you could give an example or two of this.

Joel Spolsky did a great job describing how modern browsers and much else are led astray by Postel's law: http://www.joelonsoftware.com/items/2008/03/17.html
Post reply on HN