Jules Richardson wrote:
Doug Jackson wrote:
Unfortunately, you can't work on the basis
that image data is not
hostile any more.
That's what application libraries are for. Yes, they are larger that
rolling your own, but they are also more robust.
Yes, that's all well and good when such libraries are available - but my
point was that it's not too difficult to write a TIFF decoder for a
system that had no TIFF support if it were needed. JPEG support I expect
is considerably harder to implement.
Yup. TIFF is a no-briner to decode. JPEGs, OTOH, employ a
DCT to map the image data to a set of "gains" (of a sort).
Much more *math* involved -- and *theory*. TIFF is just
bit banging...
As an aside: I've never quite understood these OS
image vunerabilities.
Doesn't any modern OS provide sufficient protection such that a process
can't just stomp all over memory at random? Unless the problem is just a
Windows thing...
Well, the problem would be present to some degree in "protected"
environments as well. E.g., view a picture as root and there's
nothing from preventing the errant code from invoking *any*
library function, etc.
But, I understand your point. Why can't you put the stack in
a separate "segment" (intel-speak) and give that segment *only*
read/write attributes (i.e. no execute). This stops hackers
from executing code on the stack. Same could apply to
purely
*data* "segments".
But, it doesn't prevent someone diddling (that's a technical
term; it means "screwing with" :> ) the contents of the stack
and thereby effecting a return to some portion of the *text*
space that does their bidding for them. Perhaps returning
to the middle of a multibyte/word instruction sequence that
*coincidentally* does something they want?
Of course, they have access to *your* binaries (if you
are running an O-t-S OS) so they can hunt around for whatever
byte sequence they happen to want.
Still, seems like a longshot. I'd imagine most exploits could
be prevented just by removing the execute ability from segments
that are known NOT to contain code.
[I'm intensely interested in this as to how it can be done
to make applications in consumer devices "hacker hardened"]