Re: Buffer Overflows (was Re: (no subject))
On 27 Apr 2000, Oleg Goldshmidt wrote: If you must code in C, at least use the safe routines in glib (for example g_strdup_sprintf) rather then using unsafe functions such as sprintf. This might be not feasible if you need to write portable code (nor will be snprintf(), which is non-standard, IIRC). You need to get into the habit of putting checks in your code to prevent buffer overflows. To reiterate my point: use glib instead of libc. Glib is *very* portable. -- Moshe Zadka [EMAIL PROTECTED]. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
On 27 Apr 2000, Oleg Goldshmidt wrote: To reiterate my point: use glib instead of libc. Glib is *very* portable. What do you mean? What if your target platform does not have glibc? This might be outside of your control... Come to think of it, it usually *is* outside of your control. Welcome to the real world :-(. Can you please try to read what you're replying to? I said nothing about glibc, I talked about glib. Glib is built on top of libc (any libc), and supplies many useful functions. -- Moshe Zadka [EMAIL PROTECTED]. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
Moshe Zadka [EMAIL PROTECTED] writes: On 27 Apr 2000, Oleg Goldshmidt wrote: To reiterate my point: use glib instead of libc. Glib is *very* portable. What do you mean? What if your target platform does not have glibc? This might be outside of your control... Come to think of it, it usually *is* outside of your control. Welcome to the real world :-(. Can you please try to read what you're replying to? I said nothing about glibc, I talked about glib. Glib is built on top of libc (any libc), and supplies many useful functions. Consider glibc a typo, and s/glibc/glib/g in what I wrote. -- Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | [EMAIL PROTECTED] "... We work by wit, and not by witchcraft; And wit depends on dilatory time." - W. Shakespeare. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
On 27 Apr 2000, Oleg Goldshmidt wrote: Moshe Zadka [EMAIL PROTECTED] writes: On 27 Apr 2000, Oleg Goldshmidt wrote: To reiterate my point: use glib instead of libc. Glib is *very* portable. What do you mean? What if your target platform does not have glibc? This might be outside of your control... Come to think of it, it usually *is* outside of your control. Welcome to the real world :-(. Can you please try to read what you're replying to? I said nothing about glibc, I talked about glib. Glib is built on top of libc (any libc), and supplies many useful functions. Consider glibc a typo, and s/glibc/glib/g in what I wrote. -- Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | [EMAIL PROTECTED] "... We work by wit, and not by witchcraft; And wit depends on dilatory time." - W. Shakespeare. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Moshe Zadka [EMAIL PROTECTED]. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
"David Tabachnikov (NetHunter)" wrote: Nobody was talking about GLIBC, Moshe was talking about GLIB, the library that is under GTK+, which provides safe and portable alternatives to the libc5/6(aka glibc) and everything else. GLib (iirc) runs on IRIX, AIX, Windows, Linux, *BSD, DOS, BeOS, MacOS, PalmOS, and anything else you can think of. Oleg Goldshmidt wrote: Moshe Zadka [EMAIL PROTECTED] writes: To reiterate my point: use glib instead of libc. Glib is *very* portable. What do you mean? What if your target platform does not have glibc? This might be outside of your control... Come to think of it, it usually *is* outside of your control. Welcome to the real world :-(. Sorry, ppl , but IMHO Oleg had pointed out a very strong point. Imagine you are to distribute small utility, which takes, say, 300 kb. But, instead of using libc and debugging your code to death, you decided to rely on glib to provide it to you. As a programmer, you are to give out the cleanest code one can provide (well, we are talking very hypothetical programmer here). But as code provider, you must make sure that your code will fit into its place without headaches. In such a case you are to wind up by including glib in your distribution. This can make sence for a large and supervisiored program, but the rule of thumb says that distributable program must be distributable with less overhead than its size. #ifdef DO_NOT_TRY_IT_AT_HOME as an example with completely different, yet same, nature, consider yourself producing cocaine in Columbia. Well, little effort, big money etc. Some danger to be caught and vivisected, or vivisected, and then cauhgt, but forget it. We are talknig technology. sad smile The algorythm is following: take a bag of coke leaves, and pur it with sulfuric acid. After 10 hors or so, wash it and sell it. 10 litres of acid per bag. However, in real world, cocaine is not produced in situ, but, rather at some distance. Therefore, coke leaves are dropped in big pool and being washed with acid. One will get a lot more product using the proper technology, but real world says his naah, and you are wasting acid, and you are wasting coke leaves, just to make the production line working. #endif Again, welcome to Real World of Real users. Forget all hope, yer, who enters there. P.S. That was rather strange example. However, there is huge cocaine industry out there, and, unfortunatly for us and our children it works. Let me say this third time: welcome to hell. -- Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | [EMAIL PROTECTED] "... We work by wit, and not by witchcraft; And wit depends on dilatory time." - W. Shakespeare. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Best Regards, David Tabachnikov (NetHunter) Please sign the Linux driver petition at http://www.libranet.com/petition.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- --- Omer Mussaev mailto:[EMAIL PROTECTED] 051-308-214 http://www.cs.bgu.ac.il/~omer = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
Omer Mussaev [EMAIL PROTECTED] writes: Sorry, ppl , but IMHO Oleg had pointed out a very strong point. Imagine you are to distribute small utility, which takes, say, 300 kb. But, instead of using libc and debugging your code to death, you decided to rely on glib to provide it to you. As a programmer, you are to give out the cleanest code one can provide (well, we are talking very hypothetical programmer here). But as code provider, you must make sure that your code will fit into its place without headaches. In such a case you are to wind up by including glib in your distribution. Right. Actually, I was making an even stronger point. Imagine a situation whereby you cannot include glib in your distribution, period. There are abundant cases in this mad mad mad mad world where you do not have control over your target platform or what you can or cannot use on it. "No third-party code" regardless of the license is not such an uncommon requirement. Does anyone doubt that "no open source code" is used here and there? Both will preclude glib (or glibc for that matter), and these are just the most obvious examples. Even ANSI C might be too wide in pathological cases. Just as a curiosity, I know of at least one case where a requirement was not to use malloc()/free() in the code [well, at least not easily]. Don't ask for details, just take my word for it. Again, welcome to Real World of Real users. Forget all hope, yer, who enters there. Sad chuckle. -- Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | [EMAIL PROTECTED] "... We work by wit, and not by witchcraft; And wit depends on dilatory time." - W. Shakespeare. = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
If you must code in C, at least use the safe routines in glib (for example g_strdup_sprintf) rather then using unsafe functions such as sprintf. This might be not feasible if you need to write portable code (nor will be snprintf(), which is non-standard, IIRC). You need to get into the habit of putting checks in your code to prevent buffer overflows. To reiterate my point: use glib instead of libc. Glib is *very* portable. Speaking of snprintf (and strncpy and strncat for that matter), it seems that these functions have two major prolbems: 1. Big time penalty, and 2. Weired behaviour. That is why, as far as string functions manipulations go, it is recommended to use the functions that are used in OpenBSD, namely strlcpy(3) and strlcat(3). Read more about it at the "Secure-Programming" HOWTO. Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Buffer Overflows (was Re: (no subject))
On Thu, 27 Apr 2000, David Tabachnikov (NetHunter) wrote: Nobody was talking about GLIBC, Moshe was talking about GLIB, the library that is under GTK+, which provides safe and portable alternatives to the libc5/6(aka glibc) and everything else. it looks like there is a quarel here between different views. one of those that deal with GPLed software, or are linux-centric, for which glib is a natural extention, as it has the right license, and now comes with the major linux distributions. the other - of people that have to deal with unsupported OSes, or with limitations of management as to what software may be used, or those that simply don't want to have to distribute yet more components with their software. if you can live with using glib - go right ahead and use it. if various restrictions don't allow you to use it - then don't. btw, last time i tried compiling glib on a solaris 2.5.1 system - compilation failed (and few minutes of looking for the problem did not suffice to fix it). GLib (iirc) runs on IRIX, AIX, Windows, Linux, *BSD, DOS, BeOS, MacOS, PalmOS, and anything else you can think of. does it run on LynxOS? Psos? Vxworks? OS/390 open edition? guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Buffer Overflows (was Re: (no subject))
Of course, the best way to avoid buffer overflows is to use good
libraries, or even better a good language. Neither Python nor Perl nor
Guile nor Tcl will *let* you have a buffer overflow as long as the
implementation is bug free. Since you are relying anyway on external
code (e.g., libc), might as well use a language where this is the only
possible source for buffer overflows. If you must code in C, at least
use the safe routines in glib (for example g_strdup_sprintf) rather then
using unsafe functions such as sprintf.
being-careful-is-easier-when-not-leaving-on-the-edge-ly y'rs, Z.
On Wed, 26 Apr 2000, Yosi wrote:
Buffer ovrflow is one of the most common security bugs in software.
Hoever, imho, relying on such tools as Lucent's library is not a good
methodology. A programmer must be security-oriented when writing code. In
the "Secure-Programming HOWTO", it says that "Paranoia is a virtue". That
is, the programmer's role is more than just compile his code with a library
that is supposed to defend his code from buffer overflows. He must audit his
code for potential hazards, and write the code in such a way, that buffer
overflows and other security
issues won't happen in the first place. Lucent's library is a welcome
addition to a set of tools that already exists in the Linux world
(StackGuard and StackShield are just two examples). However, they
must not be relied on to provide total security.
Yosi
P.S
Speaking of StackGuard, here is a recent post I found on BugTraq that
compares Lucent's library to StackGuard:
JEFF PFOHL wrote:
Does anyone know anything about this?
http://www.bell-labs.com/org/11356/html/security.html
Solar Designer has posted his analysis to the Linux security-audit
mailing list
http://www2.merton.ox.ac.uk/~security/security-audit-24/0069.html
Perry Wagle (principle StackGuard developer, cc'd) has written an
analysis comparing StackGuard to libsafe (attached). The summary is
as follows:
* Use StackGuard where you can, because it is safer:
o Libsafe only wraps selected string library functions. Buffer
overflows affecting other library functions or user-written
loops will not be protected
o Libsafe attempts to wrap these functions by parsing the
stack, but it doesn't always succeed. In particular, libsafe
depends on the existance of the frame pointer, and fails when
it isn't present, as happens if the code was compiled with
-fno_fp, or if the optimizer removed the frame pointer.
* Use Libsafe where you cannot use StackGuard, i.e. for
binary-only applications.
My further comment on libsafe: the paper that the authors will be
presenting at USENIX in June presents two forms of defense ("library
intercept" and binary-rewrite (BRW)) and only the library intercept
appears to be embodied in the publicly available libsafe, which is
why libsafe only protects against overflows that use particular
string library functions.
The BRW method is a pseudo-compiler that can transform binaries into
"safe" programs by transforming the binary. It copies program onto
the heap, inserting checks as it goes. The copy-to-the-heap is to
make space for the additional checks. I really like the BRW method,
and hope it becomes available.
If my understanding is mistaken, and BRW is actually in the
distributed libsafe, please correct me.
Crispin
-
Crispin Cowan, CTO, WireX Communications, Inc.http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
JOBS! http://immunix.org/jobs.html
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
--
Moshe Zadka [EMAIL PROTECTED].
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com
=
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
