, 2005-02-14
More and more, we see articles questioning the security of a given platform based solely on the number of advisories published -- and this approach is simply wrong.
Expand all |
Post comment
|
More Advisories, More Security
, 2005-02-14 More and more, we see articles questioning the security of a given platform based solely on the number of advisories published -- and this approach is simply wrong.
Expand all |
Post comment
|
|
|
Privacy Statement |
In open-source packages, code boundaries are generally pretty tight. The reason that integrating an HTTP Server and a web browser into an OS (e.g, Windows 2000) is horrible from a security POV is because of *COMPLEXITY*.
Complexity necessarily worsens security. It makes vulnerabilities more likely, because it necessarily requires more difficult programming, and making inter-associations among s/w packages is a recipe for bugs. And, after all, security issues are just that: serious bugs. Obviously, they warrant a priority higher than that of normal bugs, but they are, after all, bugs.
In addition to the inherent weakness created by complexity, it lengthens patch time once a vulnerability is uncovered, as more extensive testing is required for a patch to be considered stable.
For an example of complexity causing vulnerabilities, look at CAN-2004-0636, the critical vulnerability in the AIM URL handler (discovered by Yours Truly). The routine charged with handling away messages allocates a static buffer on the stack. In older releases, this buffer *cannot* be overrun, because the only "attack" is to fill a text box with more input than its upper limits allow.
Fast forward to 5.x. The addition of the aim:goaway URI spec allows direct user input to be sent to this same function. That static buffer that previously held input < 128 bytes can now hold whatever the Windows Shell can pass to it.
What happens when you try to stuff 1K of data into a 128 byte buffer? Everybody on three... 1... 2... 3... buffer overflow.
Had an external source of input not been linked to a function that was designed to handle internally-trusted data, we would never have seen this vulnerability.
It was an unnecessarily complex way of handling what never needed to be done. Thus, software complexity not only degrades patch timelines, but actually *causes* vulnerabilities. After all, how many buffer overflows are there in "hello world"?
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/columns/299/30697#30697