C considered harmful: was Debian attacker may have used new exploit
Peter Hiscocks
phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org
Thu Dec 4 14:35:03 UTC 2003
Marcus -
Thanks for the references. I may be incorrect, but I believe Heather Hinton
was involved with the 'stackguard' project. She's now with IBM it Austin,
Texas.
Peter
On Wed, Dec 03, 2003 at 11:36:04PM -0500, Marcus Brubaker wrote:
> On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote:
> > OK, I hate to flog a dead horse but really:
> >
>
> Hmmmm, this is likely to start a looooong drawn out flame thread.
> Language arguments almost always do. So, with trying to prevent that in
> mind, I will avoid standing up for my general language of choice and
> instead offer an alternative.
>
> > This exploit, like others against Unix machines many years ago, was based on
> > a buffer overflow dumping the user into supervisor space. This, in turn, is
> > a direct result of the fact that the C programming language does not check
> > or enforce limits on a string length or buffer size - that's left up to the
> > individual programmer.
> >
> > Surely, given the importance of security, it should be possible to fix the C
> > language (or my preference, use a different one) to do systems programming.
> > After all, C is not so much a systems programming language as a high-level
> > version of assembly language.
> >
>
> "Fixing" C in the sense you're imagining will never happen and people
> often do use other languages for specific tasks. However, other
> languages are not immune to buffer overflows as most of them are
> actually written in C themselves.
>
> The better solution is things like stackguard[1] and execshield[2] which
> actually fix the root problem: the stack should NOT be executable and
> neither should most of the heap and likewise portions of memory which
> are actively executable shouldn't be writable from userspace.
>
> > (Incidentally, a former profs at Ryerson, Heather Hinton, was working on
> > such a mechanism to prevent stack overflows. I guess it's never been widely
> > adopted.)
>
> Hinton...any relation to Geoffrey Hinton? At any rate, many people have
> (and continue) to work on stack guards and similar solutions. See [1]
> and [2]. As with all security measures, its just a question of getting
> people to use them.
>
> --
> Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org>
>
> [1] http://www.immunix.org/stackguard.html
> [2] http://seclists.org/lists/linux-kernel/2003/May/0371.html and http://people.redhat.com/mingo/exec-shield/
>
> --
> The Toronto Linux Users Group. Meetings: http://tlug.ss.org
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
--
Peter D. Hiscocks
Department of Electrical and Computer Engineering
Ryerson University,
350 Victoria Street,
Toronto, Ontario, M5B 2K3, Canada
Phone: (416) 979-5000 Ext 6109
Fax: (416) 979-5280
Email: phiscock-g851W1bGYuGnS0EtXVNi6w at public.gmane.org
URL: http://www.ee.ryerson.ca/~phiscock
--
The Toronto Linux Users Group. Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml
More information about the Legacy
mailing list