On 09/28/2014 04:50 PM, Valdis.Kletnieks@vt.edu wrote:
On Sun, 28 Sep 2014 15:06:18 -0600, "Keith Medcalf" said:
Sorry to disappoint, but those are not changes that make the system more vulnerable. They are externalities that may change the likelihood of exploitation of an existing vulnerability, but does not create any new vulnerability. Again, if the new exploit were targeting a vulnerability which was fully mitigated already and thus could not be exploited, there has not even been a change in likelihood of exploit or risk.
So tell us Keith - since you said earlier that properly designed systems will already have 100% mitigations against these attackes _that you don't even know about yet_, how exactly did you design these mitigations? (Fred Fish's thesis paper, where he shows that malware detection is equivalent to the Turing Halting Problem, is actually relevant here).
In particular, how did you mitigate attacks that are _in the data stream that you're charging customers to carry_? (And yes, there *have* been fragmentation attacks and the like - and I'm not aware of a formal proof that any currently shipping IP stack is totally correct, either, so there may still be unidentified attacks).
For that matter, has the *specification* of tcp/ip been proven to be "correct" in any complete way? In particular is it correct in any useful sense in the face of attackers that are ready and willing to spoof any possible feature of tcp/ip and its applications? (e.g. spam protection involves turning several MUST clauses from 821/822 to MUST NOT; the specs were not themselves reasonable in the face of determined attackers. And unfortunately Postel's famous maxim fails in the face of determined attackers, or at least the definition of "liberal" has to be tempered a lot.) The main serious effects of slammer, for example, were not directly from the worm itself, but due to the fact that the worm generated random addresses (at about 30k pps on a 100meg ethernet) without regard to "address family", and most default router's cpus were overwhelmed issuing lots of "network unreachable" icmp messages (which I think were a MUST at the time). Now that we've run out of spare v4 addresses, we wouldn't get so many unreachables :-) Fortunately most of our vulnerable customers back then were behind T1's so it didn't really hit us too badly. The only real workaround at the time was to disable unreachables, which has other undesirable side effects when the customers are mostly behaving. (Unplugging worked best.) (and at least that worm didn't write anything to disk, so a reboot fixed it for a while...) I know that there are features (e.g. fragmentation, source routing, even host/net unreachable etc etc) in the spec that fall down badly in the face of purposeful attacks. And things like the 7007 incident, where DATA passing between only a few nodes in the larger internet caused a very large-scale cascading failure. Jay mentioned another; there were approximations to 7007 a few times a year for several years after that incident (one involved routing the whole internet through Sweden). Mitigations for things like that are time-varying (e.g. IRR, if enough people actually used it (and in the face of tcp/ip forgery, that isn't sufficient either)...), and indeed one has to include the entire internet (and all of the people running it) as part of the system for that kind of analysis to mean anything. And can anyone prove that any one of the 7007-like incidents were really accidents or not? For that matter, maybe they were "normal accidents" (see Perrow - recommended reading for anyone involved with complex systems which the internet certainly qualifies (The internet is *much* more complex than the phone system, and there must be people in NANOG who remember the fallout from the Hinsdale fire (fast busy, anyone? Even in Los Angeles...)). (if one believes that 7007 was accidental, then it was induced by a combination of a misfeature in ios (11.x?) (mitigated with some of the "address-family" features in 12.x, though I don' t know if that was the intent) and a serious lack of documentation in matters concerning BGP. And a lack of error-checking outside that site (though IRR was the only source of check-data at the time and was (still is?) woefully incomplete.) The halting problem comes up in connection with _data_ handling in any computer with even a language interpreter (e.g. is browser-based javascript complete enough for the halting problem to apply to it? I think so. Java certainly is, though most browser-based java is supposed to be sandboxed. Perl, python, ruby, php all are.) (and in any real piece of equipment, can any of these make permanent state changes to the retained memory (flash or disk) in the computer? If so then this halting problem equivalence gives us trouble even if no changes are made to any executable programs (including shared libs) that came with the computer.) (especially true if the box is a router with any sort of dynamic routing, even ARP/NDP) How, for example, am I to know a priori for all possible <script src= strings, the difference between a 3rd party download of jquery and a malicious downloader *before running the download* (for that matter, even after...) Whitelisting does not help here in the face of attackers that spoof protocol features, in this case filenames and/or DNS. Noscript and related (e.g. chrome's script protection) whitelist whole sites, which is nowhere near granular enough, but even then is a pain for the user to manage. If the user is the proverbial grandmother, it is probably impossible to manage. -- Pete