, SecurityFocus 2000-09-04
Last month's Brown Orifice program opened a backdoor to an insecure future. Can open source save the day?
Expand all |
Post comment
Open Source Solution
2000-09-05
Pete Kofod (2 replies)
Pete Kofod (2 replies)
"All bugs are shallow" is a delusion of Open Source Arguments
2000-09-08
peter (at) smalltalk (dot) org [email concealed]
peter (at) smalltalk (dot) org [email concealed]

Look at the Java bug: The two problems were both in Java classes. While these classes were compiled for a special purpose, namely to serve Netscape, they represent a single module independent of the browser. It's not the browser-Java interaction that's at fault but the Java-Java interaction. The browser only comes into it by way of saying that the bug really only affects its version of the module. The JPEG bug is the same way: Only that version of that particular code is the problem, not the interaction with Netscape.
Under ideal circumstances, only expected forms of input and output appear, and bad input is rejected. Inter-module bugs pop up when two modules are both incorrectly handling bad input; one takes input from a malicious user, amplifies or transforms it to bad output, which is then accepted by the second weak module, forming the bug. I don't view this as a problem caused by linking the modules but one caused by not robustly coding them in the first place.
I'm still a firm believer in modular coding. A truly robust module can't be a security threat even when linked to other modules. The most it can do is to pass on data that it can't verify to be bad, because it's not its job to know. A JPEG module is supposed to know if an image file is valid or not; Netscape doesn't need to know that, because it's the JPEG module's job to find that out, so it will simply send the module whatever .jpg image it gets. Java is supposed to handle its own security, and problems of interaction between Java classes are the Java interpreter's responsibility.
If we just look at the Java-Java situation, there are a few valid points there. Weird interaction between objects can happen in any suitably complex system. But then, this is a case of security protocols not being followed. The problem is not that no one anticipated a problem but that no one verified that the code was working according to spec. Java is supposed to fail security checks in very specific ways. If either hole in the code had been closed, there would be no bug; so again I'd blame the weaknesses of the individual segments.
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/articles/80/3309#3309