mec@ardent.com (Michael Chastain) (11/23/88)
Here are my assumptions: (1) Attacks against a known binary server (e.g. Vendor X, Release Y) are easier to accomplish than general attacks "through the interface". (2) Some machines on the Internet were unaffected by the recent virus because they had recompiled /etc/fingerd; e.g., with nameserver support. Sorry, I can't find references. How about a "salt" utility that transforms an executable to another executable, while adding extra bytes here and there to make all the data addresses come out different? This is even easier to do at link time. Suppose that you have the capability to relink your operating system (e.g., to add device drivers). Do so, and stick in some padding here and there. Now imagine that Internet Worm II shows up on your system and tries to read kernel data space to get juicy network data (e.g. /dev/kmem on Unix). Your physical memory doesn't look like everybody else's! So if the worm is carrying around kernel data addresses, it doesn't get to do what it wants on your system. I think this idea can be taken further. For instance, if you have source, you could protect private data structures by randomizing the order of their structure members. This wouldn't fool a smart hacker, but it might fool a dumb worm. This would protect against "read the clist and discover what people are typing" attacks. An unrelated, controversial statement: protecting your user's files is now the second most important thing. The first most important thing is protecting your network connections. Michael Chastain Ardent Computer mec@ardent.com "He who dies with the most FRIENDS wins."
jam@RADC-LONEX.ARPA (11/24/88)
>From: vsi1!ubvax!ardent!mec@ames.arc.nasa.gov (Michael Chastain) > >How about a "salt" utility that transforms an executable to another >executable, while adding extra bytes here and there to make all the >data addresses come out different? > >This is even easier to do at link time. Suppose that you have the >capability to relink your operating system (e.g., to add device >drivers). Do so, and stick in some padding here and there. Would this accomplish your purpose? Two ways I see around it under UNIX (not sure about other systems): 1) use the symbol table to find addresses.... 2) the executable is stripped... if you have any idea of the code for known executables then crawl through the text area if at all possible and get the new address. The second is a complicated procedure, but if you have root access would be possible. I suppose it is a good argument for keeping the source code hidden from the entire world. I would rather see good audited programing practices so the potential for errors is lower. >Now imagine that Internet Worm II shows up on your system and tries to >read kernel data space to get juicy network data (e.g. /dev/kmem on >Unix). Your physical memory doesn't look like everybody else's! So if >the worm is carrying around kernel data addresses, it doesn't get to do >what it wants on your system. I should hope that /dev/kmem is readable only by root and certain utilities. But this is affected by the same statements I made above. The mere fact that the kernel has structure linkages means you can follow them. >I think this idea can be taken further. For instance, if you have >source, you could protect private data structures by randomizing the >order of their structure members. This wouldn't fool a smart hacker, >but it might fool a dumb worm. This would protect against "read the >clist and discover what people are typing" attacks. Possible. But is it worth it? You always run the risk of things working off expected alignments in structures. Also many structures in operating systems are optimized against the machines use of memory types (longs, shorts, etc.). Joel