If it contains a CPU (that is designed to run code) and RAM (that is
designed to store code) and you can trick the CPU in running code you
tricked it into putting in the RAM, then it can do anything it wants
with the other hardware available, anything it is designed to do.
> If you want to break it, it's easier to hit it with a
> hammer or an axe. There is not any capability to "break in".
> Even if there was, what could you do? Shut off a motor?
> Screw up the ignition timing? Put porn pictures into
> medical images?
Or, be a proxy on the inside of J. Random Paranoid Corporate Network
that can relay stuff, snoop, sniff interesting stuff that is being
printed, etc. I mean, how about establishing an http connection out
to a computer controlled by the Bad Guy, and over that he tunnels
whatever he wants? And maybe it gets setup by putting some rogue
Postscript in a file he somehow conspires to be printed.
> Most embedded systems don't have network capabilities.
Certainly if the embedded system has extremely limited IO (Coke
vending machine?) there are limited opportunities for exploiting
things like buffer overflows.
But even Coke machines are starting to get IO: to report inventory and
apparent function to the vending company, some to even allow payment
via a cellphone. Don't think that embedded == isolated, for it is
becoming less and less true.
My cellphone has embedded software in it, it can receive e-mail.
(There was a recent story of a mal formed e-mail message that would
hard-crash some Nokia phones such even a power cycle wouldn't fix it!)
> There is no way that you can teach your Hewlett-Packard
> printer to become a network rogue and break into the
> Pentagon --regardless of what you send it.
Boy, are you ever complacent. Just because HP manages to largely
obscure the details of its internal CPU and RAM doesn't mean it ain't
there and potentially exploitable.
I have a friend who used to be really into desktop publishing,
Illustrator, his font collection, etc. He frequently made the
distinction between a "hardware RIP" and a "software RIP". His point
was actually that the embedded systems were better productized, but I
still corrected him and said they were both software, one was simply
embedded. He never seemed to get the point, and you don't either.
-kb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/