When I read this, the first thing that came to mind was that in theory, you could do a similar thing with electricity, and then maybe the electric company wouldn't have to be a sanctioned monopoly anymore.
And then that thought went the other direction: maybe the broadband internet access market will start looking more like the electricity market, rather than the other way around.
As things stand now (in the US at least), broadband competition is all but non-existent for the same reasons as more conventional utilities: the prohibitively high infrastructure cost for competitors to enter the market. If this experiment doesn't enable viable competition, maybe it's time to think about applying the regulated-monopoly idea to internet access.
Basically, in the header block for a unit of WMF script contains a "length" field which specifies how long the current unit is. This is standard for this sort of file, and is the primary way to avoid buffer overruns (if you force the data to tell you how big it's supposed to be, and then double check that while reading, you make sure you have enough buffer space to store it all -- otherwise you might read too much, overrun the end of the buffer and trash an important function pointer or something..)
In this case, the smallest possible "length" value is 6, because the header itself takes 6 bytes, so even if the unit had no actual data, the length field itself and the unit's command code is a minimum of 6 bytes.
To trigger the exploit, the length must be set to 1. Not 2, 3, 0, or some other equally invalid value, but only the value "1". Any other value has no effect at all.
I don't think it's surprising that a piece of code might behave in an odd way if it's given invalid input, i.e., if a buffer length is wrong.
Again, agreed. But again, the catch is in the particular kind of odd behavior. If I were writing that code and it hit an invalid length, I'd probably abort processing of the whole file, presuming data corruption. Failing that I'd just skip over the flawed block and proceed with processing the next one. In that case, I could imagine not checking the length very carefully and just going to " + " to process the next block -- this would produce the observed "next byte" pointer.
The problem is in the semantics: I said *process* the next block, not *execute* it. If anything this would just cascade into more error cases, since the data that was expected to be the "next block" would almost definitely also have a malformed header (since it wasn't intended to be a header at all), etc.
So, I guess you're right - the tipoff is still that actual code is executed without having to be specifically pointed to (i.e. buffer overrun), and that it's executed in its own thread, rather than taking over the processing thread that was interpreting the metafile in the first place.
Agreed, it doesn't seem like the kind of "feature" that was designed in top-secret MS design documents or developed in meetings.
But I still have a hard time seeing how code would *accidentally* behave like this. An invalid length should abort processing right off the bad, for one thing; "falling through" might be an explanation, but what possible code could be "fallen through" into that would set CPU execution *inside* the metafile -- moreover, would set CPU execution to the *next byte* after the erroneous header block. That's awfully convenient; if it were a mistake, I'd expect code execution to begin at some other random location, probably influenced by whatever happened to be in the register or some temporary pointer variable at the time. But the very next byte? That's too insanely convenient -- you get to provide your key *and* your payload in the *same* place.
You could argue that buffer overrun exploits do the same thing, but the idea of the buffer overflow is to specifically overwrite the function-return pointer to *make* it point at your code. In this case, the exploit doesn't have to specify the location of the code to execute, Windows does that for you. Too convenient.
This does look awfully like a special-case trigger. The idea of a backdoor is to have it look for a specifically crafted but completely nonsensical and invalid input sequence -- this serves as the "key" to the backdoor, ensuring that no other designer or user accidentally stumbles onto it. Since we assume that legitimate users and developers will only provide valid input, we design our "key" to be definitely invalid.
For me, that length==1 trigger is the most convincing evidence. It's not just that it's the wrong input, it's that it's the one specific value of wrong input that triggers the behavior. That seems like design.
Questions:
1) Is there any reason to believe the results from this company would be valid "this time", if they never were before?
2) Can we please refrain from common basic grammar mistakes on the front page? 'There' is not a posessive...
Fair use re: parody has nothing to do with being funny. In fact, "parody" is not explicitly defined as fair use (nowhere in US law does it say that "parody", i.e. something a reasonable person would call "parody", is inherently fair use just because it could be called "parody"). Parody is (historically, usually) considered fair use because it involves "commentary" and "criticism", which are explicitly defined as "fair use" in US copy right law (sect. 107 is posted several places in this thread).
Adding a cymbal crash to a song probably wouldn't be considered "commentary" or "criticism" by any judge or jury. Using a previous work's style and changing it's content in order to comment on/criticize the original work or the original work's author, as is (IMHO) clearly the case here, probably would be considered "commentary" and "criticism".
Slashdot Mirror
oh my... I am slightly embarrassed at how hard I laughed at this.
When I read this, the first thing that came to mind was that in theory, you could do a similar thing with electricity, and then maybe the electric company wouldn't have to be a sanctioned monopoly anymore.
And then that thought went the other direction: maybe the broadband internet access market will start looking more like the electricity market, rather than the other way around.
As things stand now (in the US at least), broadband competition is all but non-existent for the same reasons as more conventional utilities: the prohibitively high infrastructure cost for competitors to enter the market. If this experiment doesn't enable viable competition, maybe it's time to think about applying the regulated-monopoly idea to internet access.
Basically, in the header block for a unit of WMF script contains a "length" field which specifies how long the current unit is. This is standard for this sort of file, and is the primary way to avoid buffer overruns (if you force the data to tell you how big it's supposed to be, and then double check that while reading, you make sure you have enough buffer space to store it all -- otherwise you might read too much, overrun the end of the buffer and trash an important function pointer or something..)
In this case, the smallest possible "length" value is 6, because the header itself takes 6 bytes, so even if the unit had no actual data, the length field itself and the unit's command code is a minimum of 6 bytes.
To trigger the exploit, the length must be set to 1. Not 2, 3, 0, or some other equally invalid value, but only the value "1". Any other value has no effect at all.
I don't think it's surprising that a piece of code might behave in an odd way if it's given invalid input, i.e., if a buffer length is wrong.
Again, agreed. But again, the catch is in the particular kind of odd behavior. If I were writing that code and it hit an invalid length, I'd probably abort processing of the whole file, presuming data corruption. Failing that I'd just skip over the flawed block and proceed with processing the next one. In that case, I could imagine not checking the length very carefully and just going to " + " to process the next block -- this would produce the observed "next byte" pointer.
The problem is in the semantics: I said *process* the next block, not *execute* it. If anything this would just cascade into more error cases, since the data that was expected to be the "next block" would almost definitely also have a malformed header (since it wasn't intended to be a header at all), etc.
So, I guess you're right - the tipoff is still that actual code is executed without having to be specifically pointed to (i.e. buffer overrun), and that it's executed in its own thread, rather than taking over the processing thread that was interpreting the metafile in the first place.
Agreed, it doesn't seem like the kind of "feature" that was designed in top-secret MS design documents or developed in meetings.
But I still have a hard time seeing how code would *accidentally* behave like this. An invalid length should abort processing right off the bad, for one thing; "falling through" might be an explanation, but what possible code could be "fallen through" into that would set CPU execution *inside* the metafile -- moreover, would set CPU execution to the *next byte* after the erroneous header block. That's awfully convenient; if it were a mistake, I'd expect code execution to begin at some other random location, probably influenced by whatever happened to be in the register or some temporary pointer variable at the time. But the very next byte? That's too insanely convenient -- you get to provide your key *and* your payload in the *same* place.
You could argue that buffer overrun exploits do the same thing, but the idea of the buffer overflow is to specifically overwrite the function-return pointer to *make* it point at your code. In this case, the exploit doesn't have to specify the location of the code to execute, Windows does that for you. Too convenient.
This does look awfully like a special-case trigger. The idea of a backdoor is to have it look for a specifically crafted but completely nonsensical and invalid input sequence -- this serves as the "key" to the backdoor, ensuring that no other designer or user accidentally stumbles onto it. Since we assume that legitimate users and developers will only provide valid input, we design our "key" to be definitely invalid. For me, that length==1 trigger is the most convincing evidence. It's not just that it's the wrong input, it's that it's the one specific value of wrong input that triggers the behavior. That seems like design.
Questions: 1) Is there any reason to believe the results from this company would be valid "this time", if they never were before? 2) Can we please refrain from common basic grammar mistakes on the front page? 'There' is not a posessive...
No, you're missing the point.
Fair use re: parody has nothing to do with being funny. In fact, "parody" is not explicitly defined as fair use (nowhere in US law does it say that "parody", i.e. something a reasonable person would call "parody", is inherently fair use just because it could be called "parody"). Parody is (historically, usually) considered fair use because it involves "commentary" and "criticism", which are explicitly defined as "fair use" in US copy right law (sect. 107 is posted several places in this thread).
Adding a cymbal crash to a song probably wouldn't be considered "commentary" or "criticism" by any judge or jury. Using a previous work's style and changing it's content in order to comment on/criticize the original work or the original work's author, as is (IMHO) clearly the case here, probably would be considered "commentary" and "criticism".