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