3 ms·

Certainly the bulk of the blame falls on Second Life and the printer manufacturers for not validating inputs. But there's another valuable lesson about interpr

Certainly the bulk of the blame falls on Second Life and the printer manufacturers for not validating inputs. But there's another valuable lesson about interpreting binary/string blobs: don't make guesses about the format of the data from its value. You'll eventually get data that looks like one thing but isn't, and do the wrong thing with it. I run into this all the time. Just a couple weeks ago I spent a lot of time trying to track down a bug where a programmer had decided to use a de-serialization function that would take the value of a JSON field, look for an internal object with that ID and either return the object it found or initialize a new object using the string as a value (and a random ID). So guess what happened when I tried to create a new object with a value that happened to be the same as the ID of an existing object? The Win32 issue is just looking at the first few bytes of the input to determine its format (and how to try executing it) - it's somewhat hard to avoid here for legacy reasons, but a better design would use metadata associated with the input to determine its format rather than guessing.

gruez 8y ago
>but a better design would use metadata associated with the input to determine its format rather than guessing. how would that have prevented this incident? if the metadata is stored in the filesystem (as opposed to the file contents), chances are, the updater is going to blindly mark whatever it downloaded as "an executable". if it's part of the file contents, it's essentially the same as magic bytes.
cptskippy 8y ago
> But there's another valuable lesson about interpreting binary/string blobs: don't make guesses about the format of the data from its value. You could say the same about the file extension, meta data or any other means. The best thing you can do is write your code to validate the input and to fail early, explicitly, and safely if it runs into a problem.

gruez 8y ago

>but a better design would use metadata associated with the input to determine its format rather than guessing. how would that have prevented this incident? if the metadata is stored in the filesystem (as opposed to the file contents), chances are, the updater is going to blindly mark whatever it downloaded as "an executable". if it's part of the file contents, it's essentially the same as magic bytes.

cptskippy 8y ago

> But there's another valuable lesson about interpreting binary/string blobs: don't make guesses about the format of the data from its value. You could say the same about the file extension, meta data or any other means. The best thing you can do is write your code to validate the input and to fail early, explicitly, and safely if it runs into a problem.