Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Bell Labs Software Prevents Buffer Overflows

By gnuchris in News
Thu Apr 20, 2000 at 04:49:18 PM EST
Tags: Security (all tags)
Security

After posting this on LinuxLock I thought we at Kuro5hin would enjoy discussing this... especially since some of us know alot about security coding. Bell Labs has created software that prevents Buffer Overflows in Linux... Read it at Bell Labs' Free Linux Software Foils the Most Common Computer Security Attack


Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Kuro5hin
o Bell Labs' Free Linux Software Foils the Most Common Computer Security Attack
o Also by gnuchris


Display: Sort:
Bell Labs Software Prevents Buffer Overflows | 22 comments (22 topical, editorial, 0 hidden)
StackGuard have been doing this kin... (3.00 / 1) (#3)
by inspire on Thu Apr 20, 2000 at 01:36:18 PM EST

inspire voted 1 on this story.

StackGuard have been doing this kind of thing as well. since about 1998. StackGuard is a compiler (as opposed to Libsafe, which appears to be a library that you link against) that "hardens" programs compiled with it against common buffer overflows.

One of the most pertinent things to keep in mind, though, is that no amount of StackGuard or Libsafe is going to protect against bad program security design. These programs are like Linus'[1] security blanket. It's an extra layer of security, but placing too much faith on it will lead to problems down the line.

Its good to see that something is being done about these things, though.

[1] The Peanuts character, not the other guy.
--
What is the helix?

Re: StackGuard have been doing this kin... (none / 0) (#15)
by bgp4 on Thu Apr 20, 2000 at 09:29:03 PM EST

An example of using it as a "security blanket" would be Mark Crispin's comment on bugtraq the other day. He seemed surprised that the whole planet wasn't running StackGaurd. He seemed to be relying on SG catching any overflows that he left in his code. If the end user uses SG as an extra layer of security, that's great. If the developer assumes the end users are running it, the results can be disastorous.
May all your salads be eaten out of black hats
[ Parent ]
The write up is a bit short, but it... (none / 0) (#5)
by nicktamm on Thu Apr 20, 2000 at 01:42:59 PM EST

nicktamm voted 1 on this story.

The write up is a bit short, but its an interesting piece of software (not that I claim to know much about libraries and such). If I understand it, it just intercepts calls to various functions that are known for causing buffer overflows, and uses its own implementation of these functions. If that is the case, why aren't the original functions just replaced with ones which won't overflow so easily? Is this truely the first time somebody has thought of doing this, or is it just that its the first one that is getting good PR since it is from Lucent?
Nick Tamm nick-k5@echorequest.net http://www.nicktamm.org

Cute way of getting around buffer o... (4.00 / 1) (#2)
by fluffy grue on Thu Apr 20, 2000 at 02:07:03 PM EST

fluffy grue voted 0 on this story.

Cute way of getting around buffer overflow-related attacks, but I'd much rather see the code be fixed than worked around like that. Having a version of libc called, say, secure-libc which doesn't have the Bad, insecure functions (gets being the most notorious of them) would force programs to use only the secure equivalents (such as fgets).

In fact, I'd like to see an entire distribution based on this methodology. Perhaps Debian could make a secure-debian project which only compiles packages against this hypothetical secure-libc, resulting in having an entire Linux distribution which is theoretically free of buffer overflows (of course, it'd take a long time of lots of patching and bugfixing to even get a binary distribution - which is the whole POINT).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

Re: Cute way of getting around buffer o... (none / 0) (#8)
by ramses0 on Thu Apr 20, 2000 at 05:39:09 PM EST

That would be a nice idea... remove the crutches so to speak, and actually do
it right.  Debian seems like they're a great bunch of people who might actually
get around to doing this, but rather than calling it "debian-secure", you would
be more accurate to call it "debian-no-buffer-overflows", which is not the same
thing as calling it secure.

If somebody has a few months of their life to spare, you might be able to get
something like this off the ground.

On a somewhat related note, it would also be nice for this libsafe thing to
have an option for logging all times when  programs makes an insecure call that
it is swallowing.  Then you might have enough evidence to motivate your vendor
to fix the software.

--Robert

[ rate all comments , for great justice | sell.com ]
[ Parent ]
Re: Cute way of getting around buffer o... (none / 0) (#11)
by fluffy grue on Thu Apr 20, 2000 at 07:04:30 PM EST

Well, by removing the vulnerable functions from libc, it'd make it impossible to run any applications which use them. Maybe what libc-safe (yeah, -secure is a misnomer) could do is just replace the vulnerable functions with ones which do this:
char *gets(char *s) { fprintf (stderr, "This program has potential buffer overflows and will be terminated.\n"); abort(); }
(calling abort() instead of exit(255) or whatever so that we get a coredump to make it easier to find the offending call)

Hell, creating libc-safe would be easy, probably a couple hours' worth of work if even that much. The real work would be in "porting" programs (i.e. fixing them) to libc-safe. Anyone else interested in working on this? :) (Honestly, I don't have the kind of time it'd take to do this. I'm a grad student working on two research projects and working on papers and research of my own, and honestly I shouldn't even be on K5 right now. :)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

even cuter ;) (none / 0) (#19)
by hoss10 on Fri Apr 21, 2000 at 06:38:06 AM EST

> force programs to use only the secure equivalents (such as fgets).

I would go so far as to get rid of most of the string functions and replace them with the kind of strings you get in Java. Strings should be immutable. Any library function that creates (or edits) a string should allocate a new one:

char *strcat(char *dest, const char *src);

should be

char *strcat(char *src1, const char *src2);

which should leave the 2 parameters strings alone and return a newly malloced string.



[ Parent ]

Re: even cuter ;) (none / 0) (#20)
by fluffy grue on Fri Apr 21, 2000 at 01:33:04 PM EST

Well, that's kinda crappy, since then it becomes VERY memory-leak prone. What I'd rather see than that would be everyone switching to C++ and using the STL string class. It buys you a LOT, such as:
  • Being treated as a fundamental (passed by value unless explicitly by reference, etc.), making complex containment and the like very simple (map<string, string>> gives you a PERL-style array, btw :)
  • Not being limited to 8-bit char (very nice for i18n)
  • Has an explicit size rather than being null-terminated (makes some string-processing operations a LOT faster while not slowing others down)
  • Simple mathematical operations (operator+ instead of strcat, for example)
  • Easily linked to the C++ IO streams stuff, making tokenization et al real easy (strstream::operator<< and so forth)
Plus a lot of other stuff. Yeah, badly-written C++ can perform really poorly, but if its features are used responsibly, it can become VERY powerful without much speed hit. For example, the scenegraph in Solace is stored as an n-ary tree where each hierarchal node keys its children by its name, making complicated scenegraph operations very simple, rather than the traditional mechanism of storing the name within the node and requiring the programmer to search through each child for the proper named node. As a result, name lookups are O(lg n) instead of O(n) (map uses a btree by definition, and the common SGI implementation specifically uses a red-black tree), while traversals still take only O(n). In practice, they perform about the same (actually, the traditional way's probably a little faster due to the overhead of a red-black tree), but it makes the programming a WHOLE lot easier.

Similarly, it made programming my Markov chain ramble generator very simple. Rather than it being several source files with all sorts of containers and reimplementation and such, it's about 130 lines of C++, since a map<string, map<string, int< < does most of the real work. :) (This maps the first word to a mapping between second words and their chained frequency. I use another map<string, bool> to indicate whether a word can end a sentence.)

Anyway... what I'm trying to say is if you're going to completely change the semantics of libc strings to make them act like C++ STL strings except without the automatic cleanup, you'd might as well just have everyone switch to C++ and make it easier on themselves.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: even cuter ;) (none / 0) (#21)
by fluffy grue on Fri Apr 21, 2000 at 01:45:32 PM EST

(argh, posting again, since a bunch of the damned angle brackets messed up :)

Well, that's kinda crappy, since then it becomes VERY memory-leak prone. What I'd rather see than that would be everyone switching to C++ and using the STL string class. It buys you a LOT, such as:

  • Being treated as a fundamental (passed by value unless explicitly by reference, etc.), making complex containment and the like very simple (map<string, string> gives you a PERL-style array, btw :)
  • Not being limited to 8-bit char (very nice for i18n)
  • Has an explicit size rather than being null-terminated (makes some string-processing operations a LOT faster while not slowing others down)
  • Simple mathematical operations (operator+ instead of strcat, for example)
  • Easily linked to the C++ IO streams stuff, making tokenization et al real easy (strstream::operator<< and so forth)
Plus a lot of other stuff. Yeah, badly-written C++ can perform really poorly, but if its features are used responsibly, it can become VERY powerful without much speed hit. For example, the scenegraph in Solace is stored as an n-ary tree where each hierarchal node keys its children by its name, making complicated scenegraph operations very simple, rather than the traditional mechanism of storing the name within the node and requiring the programmer to search through each child for the proper named node. As a result, name lookups are O(lg n) instead of O(n) (map uses a btree by definition, and the common SGI implementation specifically uses a red-black tree), while traversals still take only O(n). In practice, they perform about the same (actually, the traditional way's probably a little faster due to the overhead of a red-black tree), but it makes the programming a WHOLE lot easier.

Similarly, it made programming my Markov chain ramble generator very simple. Rather than it being several source files with all sorts of containers and reimplementation and such, it's about 130 lines of C++, since a map<string, map<string, int> > does most of the real work. :) (This maps the first word to a mapping between second words and their chained frequency. I use another map<string, bool> to indicate whether a word can end a sentence.)

Anyway... what I'm trying to say is if you're going to completely change the semantics of libc strings to make them act like C++ STL strings except without the automatic cleanup, you'd might as well just have everyone switch to C++ and make it easier on themselves.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

w00t! It's GPL'd and everything. ... (1.00 / 1) (#4)
by bgp4 on Thu Apr 20, 2000 at 02:48:36 PM EST

bgp4 voted 1 on this story.

w00t! It's GPL'd and everything. Now if we can just get a port to FreeBSD, we'll be all set.
May all your salads be eaten out of black hats

This sounds like a Corporate (tm) v... (none / 0) (#1)
by Inoshiro on Thu Apr 20, 2000 at 02:55:07 PM EST

Inoshiro voted 0 on this story.

This sounds like a Corporate (tm) version of Stackguard. This approach is a BANDAID and adds no true security. This has been discussed on Linux-Kernel (here and here and here.

Please, audit your fscking code. Otherwise, it's not worth my processor time. (I only vote 0 instead of -1 to be sure that this info gets through ;-)



--
[ イノシロ ]
Re: This sounds like a Corporate (tm) v... (none / 0) (#10)
by fluffy grue on Thu Apr 20, 2000 at 06:59:06 PM EST

It's not quite just Stackguard. It looks like Stackguard instantiated using LD_PRELOAD. Big whoop.
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

buffer overflows suck.... (none / 0) (#6)
by hcchu on Thu Apr 20, 2000 at 03:59:19 PM EST

hcchu voted 1 on this story.

buffer overflows suck.

Re: buffer overflows suck.... (none / 0) (#18)
by Anonymous Hero on Fri Apr 21, 2000 at 02:19:31 AM EST

Depends on what side of the security fence you are sitting on :P

[ Parent ]
Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#7)
by gnuchris on Thu Apr 20, 2000 at 05:37:17 PM EST

I'm not much of a coder myself, more on the SysAdmin side, but I code a little... I think we all agree that secure code is better than using Bell Labs solution... however I do think it's a good idea, and an extra layer of safety. It would be extremely difficult to audit every peiece of code you install on your systems yourself... so if a buffer overflow makes it through, at least this will try and stop it.
"He had alot to say, He had alot of nothing to say" -TOOL-
Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#9)
by kovacsp on Thu Apr 20, 2000 at 06:46:29 PM EST

Seems like it would be a good idea to log which programs are using the insecure
functions so you know what you have to at least audit (and fix).

Of course, if it's a closed source program, you learn not to use it!


Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#12)
by gnuchris on Thu Apr 20, 2000 at 07:09:04 PM EST

Wow if it logged which programs were making insecure calls that would be great. Cause then it would be quick and easy to fix that code
"He had alot to say, He had alot of nothing to say" -TOOL-
[ Parent ]
Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#13)
by Inoshiro on Thu Apr 20, 2000 at 07:22:26 PM EST

grep "strcpy" < source.c is much more effective :-)

--
[ イノシロ ]
[ Parent ]
LibSafe, StackGuard, and Snarskii (none / 0) (#14)
by Crispin Cowan on Thu Apr 20, 2000 at 08:31:05 PM EST

Actually, libsafe owes more to a stacksmashing-protected version of libc that Alexandar Snarskii did for FreeBSD back in the mid-90s. Way before StackGuard, Snarskii's libc did stack introspection before returning from functions to detect buffer overflows that tried to smash the stack and corrupt the return address.

StackGuard generalized this concept to a compiler that will emit hardened code. If you want the protection of libsafe, then you can just get the StackGuarded version of glibc here.

The Bell Labs guys also did something else very cool: they contrived a means to provide StackGuard-like protection in raw binary code using a transformation procedure that copies the code segment to the data segment, inserting StackGuard-like checks where needed. Unfortunately, I don't see that code in the available GPL'd stuff.

Crispin
-----
CTO, WireX Communications
Free Hardened Linux

Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#16)
by Inferno on Thu Apr 20, 2000 at 09:35:26 PM EST

Hasn't Openwall been doing this for a while now?

Re: Bell Labs Software Prevents Buffer Overflows (none / 0) (#17)
by Inferno on Fri Apr 21, 2000 at 12:32:02 AM EST

Oh, and Openwall is a kernel patch - absolutely no modifcation required to existing programs. I highly recommend it, it's served me well.

[ Parent ]
False sense of security (none / 0) (#22)
by Anonymous Hero on Fri Apr 21, 2000 at 08:37:09 PM EST

According to Theo de Raadt of OBSD fame, this program would have only prevented
3 of the last 8 Sendmail attacks done via buffer overflows.

That's a pretty poor record for something that was just released.

I wonder how many Linux kiddies will d/l this piece of software, thinking it
makes them immune or drasticly aids them in fixing what should be taken care of
with *real* code auditing and good coding practices.

Ahh well.


Bell Labs Software Prevents Buffer Overflows | 22 comments (22 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!