Re: Stack growth direction to thwart buffer overflow attacks
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 08/14/03
- Next message: Bit Twister: "Re: Solution for botnets"
- Previous message: Erik Aronesty: "Re: Solution for botnets"
- In reply to: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Anton Ertl: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 14 Aug 2003 16:50:40 +0000 (UTC)
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
]That is not so. We could remove almost all, but such things are
]an inherent problem in languages like C and C++.
]Replacing sprintf by snprintf etc. does VERY little good unless
]you can GUARANTEE that the length passed to the latter is the
]correct one, is maintained correctly as the buffer is manipulated
]AND there will be no overlaps. So all you are doing is moving the
]problem around. Used appropriately, the strnxxx functions can help
]to reduce buffer overflows, but they are not a solution.
The question is not whether one can produce bug free code. The question is
whether one can produce code is is resistant to outside corruption. Passing the
wrong length to strnxxx is a bug, but it is not one that can usually be
triggered from outside (unless of course you ask the user for the value of n).
Buffer overflow attacks are triggered from outside. Can one write code such
that, assuming the code written is internally bug free, is resistant or imune
from externally (ie using just the input to the code) induced buffer overflows.
It would seem to me that the strnxxxx etc functions are a huge first step.
]Some of the qmail flammifers attacked Exim on this topic a while
]back, basing their claims of Exim's insecurity on the purest dogma.
]I checked the code. All but 6 uses of strcpy (the claimed loophole)
]were obviously safe, 4 took me a minute to check, 1 could cause
]buffer overflow only following a local root compromise, and only 1
]was in any way 'real'. Even that needed a DNS corruption (sic) to
]get past the information calls before there could be any trouble.
]I have also looked at several codes that use strnxxx religiously.
]Checking them was harder than checking Exim, because they were less
]clean. In several cases, there was the potential for buffer
]overflows by confusing the calculation of offsets and lengths,
]such as by triggering undetected overflow.
]TANSTAAFL.
]The ONLY cure is an architected language where either the compiler
]or the program can GUARANTEE to detect such things. There are (at
]least theoretically) such languages, but C and C++ are not in that
]category and cannot practically be extended or constrained to be
]in it.
]Regards,
]Nick Maclaren.
- Next message: Bit Twister: "Re: Solution for botnets"
- Previous message: Erik Aronesty: "Re: Solution for botnets"
- In reply to: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Next in thread: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Nick Maclaren: "Re: Stack growth direction to thwart buffer overflow attacks"
- Reply: Anton Ertl: "Re: Stack growth direction to thwart buffer overflow attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
