,
10 tweets,
2 min read
Read on Twitter
1/ An important basis for hacking is providing hostile input. The reason this is difficult is that engineers don't know what "input" is.
2/ Take the "Blaster" worm as an example. It worked by sending a long computer name over Microsoft's RPC mechanism. RPC works by taking internal data on one computer and sending it to another as internal data.
3/ The flaw in this thinking is recognizing that in between, it's external data, that it's "input". The computer on one end could never generate a computer name longer than 16 characters, so if that's internal data, it doesn't need to be checked.
4/ But hackers could generate RPC packets with longer computer names, and thus, it's "input", and needed to be checked. The entire model of "RPC" or "Remote Procedure Call" created in the early 1990s is therefore broken.
5/ A similar thing occurs with web pages. The same script on a website both generates the webpage and parses the input when the user hits "submit". Therefore, things like hidden fields containing price information is internal to the script and not seen as "input".
6/ So a frequent hack has been to edit the hidden fields, setting prices to from $599 to $0.01 when buying them.
7/ Things like PHPSESSIONID are seen as something internal to PHP, when it is in fact external, sent by the browser inside an HTTP cookie field, and something the user has full control over.
8/ A lot of car hacking is gaining control of one component in the car, then sending hostile messages over the CAN bus -- the internal network within a car. Engineers see CAN bus messages as internal data, not external input.
9/ In the recent Thunderclap attacks, hardware engineers have recognized the problem of exporting PCIe signals, and controlling that with IOMMU to protect against hostile input. But driver writers assume PCIe cards are internal, and thus, get hacked by hostile input.
10/ The moral of this story is this: while people can recognize "hostile" they have trouble recognizing "input".
