Godmar Back (gback@cs.utah.edu)
Sun, 21 Mar 1999 18:43:52 -0700 (MST)
> > This is interesting, because it's a subtle DoS attack. A resource > protection regime that looks out for threads that consume too much CPU > is helpless in this case. The notion of resource to be protected has to > include _any_ "system" object that can be manipulated in a damaging way. > FWIW, this is one of the oldest DoS attacks in Java that's been reported in the literature. See Dean's and Wallach's 1995 Techreport on security flaws in the HotJava webbrowser, section 3.3 In KaffeOS, I just wave my hands about this in that I say that the kernel must not expose objects on which it synchronizes internally to user processes. I also don't have a fully automated way of enforcing this. For the case of static synchronized methods a script to check for this is easily written, I think. In fact, static locks such as those found in java.lang.Math are not a problem because I can reload those classes for each process, effectively giving each process its own Math.class object. (This won't work with Sun's JVM if Math has native methods because they don't allow a native library to show up in more than one namespace). Of course, a more efficient solution is to use internal objects for synchronization. - Godmar
This archive was generated by hypermail 2.0b3 on Mon Mar 22 1999 - 08:26:00 EST