Slashdot Mirror

First of all, there's libsafe which is just a simple compile and install. Seeing as we don't know much about your specific problem, I'm not sure if it'll help.

Second to try is compiling your own custom kernel with the GrSecurity kernel patch. It has as part of it the PaX kernel patch which is very effective at protecting against overflows. You could even just install the PaX kernel patch itself, but I believe the version in GrSecurity is kept more up-to-date. You can compile it with protection turned off by default, but using the PaX tools turn on protection for just the binaries you wish to check.

Installing either (or both) of these could well help you, without the need to blow away your current install and start fresh.

I am surprised that major distributions have not picked up and run with this great tool. One of the first things I do on any new machine is to ensure that all internet-facing services are being run with libsafe preloaded.

It's the universal fix. Sort of like duct tape and J-B weld combined.

"No need to bother writing secure code cus new chips will have NX technology?"

I don't think that this segment of the programming population falls into those kind of pitfalls very often.

I know at least one other post called it a "fallback" measure, which sounds about right. It's a third line of defense against buffer overflows and the like (the first being good programming practices, the second being things like libsafe).

Sure, it is also helpful towards Microsoft; I can see how it restricts circumvention of DRM. But there are always other ways around. If you overflow into a buffer not protected by NX, you still have arbitrary code execution on your hands.

Of course, this is just what I get from the other posts and intuition. It's not like I RTFA or anything...

If more sysadmins installed this, perhaps we wouldn't have problems with so many Linux compromises? Of course it's no substitute for patching, but seems like a good additional security measure.

This is from the gnu.org software directory

The exploitation of buffer overflow and format string vulnerabilities in process stacks are a significant portion of security attacks. 'libsafe' is based on a middleware software layer that intercepts all function calls made to library functions known to be vulnerable. A substitute version of the corresponding function implements the original function in a way that ensures that any buffer overflows are contained within the current stack frame, which prevents attackers from overwriting the return address and hijacking the control flow of a running program.

The true benefit of using libsafe is protection against future attacks on programs not yet known to be vulnerable. The performance overhead of libsafe is negligible, it does not require changes to the OS, it works with existing binary programs, and it does not need access to the source code of defective programs, or recompilation or off-line processing of binaries.

S-exprs, in their commonly understood form, represent a tree. XML documents, in their specified form, represent a graph.

So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well.

I wrap all my generic containers in types that perform specific operations on the type I wish to contain.
There's a lot of advantages to doing this:

• It's more object-oriented.
• You end up with a single cast inside the object which contains the generic container.
• You get compile-time type checking.
• It's easy to make drastic changes to the container implementation without having to recode the client.

Generics is a thing java has been sorely lacking since it's birth, thank god they're getting it now at last! (yes, I do code java for a living)

I agree. Unfortunately, it will probably be abused. :(

Generic types have been added to Java for public release in version 1.5.
There is an early access release of the compiler for generics.

For those people who want generics now, there is a non-Sun implementation of generic types.

Zero-time is nicer than constant time any day. Depending on the scope of the loops, your solution is about the equivalent of declaring everything globally.

You're forgetting where the real work is done: in the loop body. The allocation of a single object prior to doing the real work is negligable. Also, as for the comment about global declarations, huh? If your loop body is so large that you cannot see a variable declaration as well as the entire body, your code has issues.

You missed note 2 in the text.

The generics in GJ provide more backwards compatability. Pizza is another story.

Your comments on 4 ignore what Jelovic wrote: "For example, in C++ one can implement schemes that improve the locality of reference. Or allocate and free many objects at once. Or play pointer tricks to make member access faster. Etc. None of these schemes are available in Java. "

I don't understand your comment about allocating and freeing objects in tandem. Also, I'm curious as to how accessing a data member can be made faster via a tool of memory indirection, a pointer.

And finally, about 5, I've seen some neat things done with template meta-programming. You don't like it because it's not elegant. And that's fair. But it still doesn't make Java faster.

Templates are hardly a panacea. You can't treat them the same way everyone has treated XML. "Oh, well let's see if we can use XML to fix this problem with our refridgerator." Their most potent use as a generative programming tool can be duplicated by hand, which honestly is sometimes easier than developing large amounts of groundwork with a template-savvy library. In this respect it doesn't make C++ any faster than Java, only easier in some situations.

Not me. I've been waiting for them ever since Pizza and GJ. The nice thing about the Java version (beyond getting rid of casts, etc.) is that unlike C++, use of generics doesn't bloat your code. The you can have hundreds of ArrayList variants, and they all make use of the one ArrayList class that exists today.

What about stackguard? Why isn't it in use everywhere? Or libsafe for that matter? Or Openwall Project kernel patch for Linux? Can anyone please tell me why no one uses it?

Rubbish! If you're in the part of the industry that doesn't just run applications on desktop boxes you're going to take Java's portability very seriously. Why? Does Sun provide a JRE for the Mac? IBM's pSeries RS/6000s? How about your zSeries mainframe? Or your Nokia mobile phone? Or your SGI box? Out here in the real world people take these other JVMs seriously.

The fact that I can performance test my code on multiple hardware platforms, multiple JVMs and multiple application servers, then make the decision about deployment, is exactly what makes Java important to me and the companies I work for.

"Even today, you better not try writing a Java compiler that compiles to anything but Java bytecode, or that extends the language."

What, you mean like

• GCJ, that uses the gcc back-ends to compile Java to native code, or
• Pizza, that adds generics, function pointers and algebraic types, or
• GJ, which is the where the Java 1.5 generics support was prototyped.

"They were very litigious in the beginning, suing Microsoft to keep them from messing with their platform. A platform they [Sun} fought fiercly to keep proprietary and closed."

I think we can both agree that Sun and Microsoft have tried (or will try) to use the law to protect their technical vision for Java and .Net respectively. The difference is in what that technical vision is. Sun sued Microsoft in order to make sure that different implementations of Java would be compatible across platforms, because that is their technical vision (remember "Write once, run anywhere?"). Microsoft are attempting to patent .Net, and the suspicion is that they will use it to prevent compatible implementations of .Net on different platforms. Now do you see the difference?

I just wanted to point people to
a project that tries to catch buffer
overflows under linux.

freshmeat entry
homepage

It transparently replaces the libc functions that are the usual targets of stack smashing attacks, and checks whether the stack frame has been overrun. If the stack has been smashed, the process gets terminated forcefully, and root (or other designated contact) gets an e-mail with all the details.

This has been out for several years now, and I am amazed that no major distribution includes this in a standard server install.

-Steve

> What you really need is generics (as in C++ templates).
>Java collections are vile, since they suffer from type loss
> even when used with "real" objects. I'm surprised that didn't
>come into this top ten; it's a major language deficiency.

I couldn't agree more. In fact, there is a proposal (from Sun in 2001 based on Generic Java) to do just this. I really hope it will find its way into Java soon, since Generic Java solves exactly the problem you are rightly complaining about.

Java does not need just to incorporate the advances in the last 7 years, but rather the advances (e.g. in type systems) of the last 20 years.

Um, how about libsafe?

-Steve

I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.

GJ is that language, A Generic Java Language Extension . Note that the page contains this link, Sun has put forward a proposal to Add Generic Types To The Java Programming Language, based on GJ.

I first came across GJ in an article, GJ A Generic Java, in the February 2000 issue of Dr. Dobb's.

Go read this paper by Philip Wadler. Particularly look at pages 6 and 8.

For the short form, take a look at my .sig below.

Funny, but Bell Labs thinks it still belongs to Lucent . . . Bell Labs' own site has a rather prominent Lucent logo on it, and the Avaya Labs site states that "It's a brand new research lab, but it can boast of a rich, 75-year-old heritage from Bell Labs". It's a spin off . . .

There are garbage collection implementations for C++ -- several actually. Or did you mean a standard garbage collection method?

And Java does have templates. Check out JSR014 and the work done by the authors of Pizza

Related, but not directly. To protect from "stack smashing" techniques (buffer overflows), run your glibc apps with libsafe. It should detect, stomp out (i.e. abort()) and email you about overflow and out-of-bounds conditions by simply adding its path to the /etc/ld.so.preload file.

The Generic Java variant supports generic types (though the types have to be object types).

Of course it's a tradeoff, all information security is a tradeoff. What you're trading is ease of use, simplicity, and convenience for accountability, verifiability, and access control. Having these tools for security is less like dominos and more like roadblocks. The more you throw up, the more you slow down attackers, and the more that are going to give up before they do any damage. Your whole post indicates a desire for bandaids to hide real bugs.

Linux implements traditional Unix security with some twists in its own unique way. We still have all the traditional tools. If you want to design a program to utilize things like chroot jails and capabilities you can do that today. HP's tools are just a nice addition to this. Linux having poor subsystem isolation is not the same as having no security at all. Now that I think about it, until we're all running Security Enhanced HURD, we won't have the overdesigned hyper-secure OS you're describing.

However, in the long term, the only solution I see to security problems is to build on foundations that have support for guarding against common bugs and analyzing security-related program properties. That means, among other things, using languages with built-in default checks for buffer overruns and using languages with type systems that can be used to verify that data doesn't get where it isn't supposed to get...

Oh you mean like this.

In different words, the Linux and Windows kernels and daemons will have to be rewritten in something other than C or C++. Sorry.

Oops, sorry, I guess SE HURD won't be enough then. I'll just have to go back and see if I have my OS/360 tapes handy ;-)

Regards,
Reid

Agreed, to an extent. Whenever I see coders beginning to argue about "secure languages" and programming languages that "don't allow" security holes, I have to laugh and recall what Bjarne Stroustrup said about C++'s (and C's) approach to such things.

I assume that a sufficiently skilled programmer can do anything not explicitly prohibited by hardware.

(I'm quoting from memory.) The "protections" of the C family of languages are meant to prevent accidents, not fraud. Y'all might check out something like libsafe, originally from Bell Labs, and released under the LGPL.

Also, Sun is planning to officially add generics to Java for the upcoming JDK1.5 release.

However, I would contend that most cases where templates are used in real world programming, they shouldn't. Readability and maintainability can go out the window without judicious care programming templates. Templates are ideal for containers, where they assist readability and maintainability. But in many (most?) cases, they result in code that is difficult to maintain.

This is, in my opinion, the reason Java will overtake C/C++ in popularity/use. Java code, with all its simplifications over C++, is easier to maintain and write. The results in fewer projects that end in failure. It also results in code bases that last longer, due to easier maintenance.

A Big Language That Everybody Can Use For Everything could maybe have these FP datatypes:

• IEEE 754 single precision
• IEEE 754 double precision
• IEEE 754 "double-extended"-compliant type
• IEEE 754 quadruple precision
• greatest available hardware-supported precision

And less tragic still if he'd put overloaded operators back in (see Steele on Java's BigNums).

This was posted in a previous Code Red article, but I think I'll include it anyway. If you're running Apache on .*N?X, use this to check for attempts (note: only goes back as far as your error_log has been rotated)

grep default.ida /path/to/apache/logs/access_log | sed "s/ .*$//g" | wc -l

(get rid of the wc part to list the IP's)

And yes, buffer overflows are generically possible, but can you get libsafe for MS products?

The Real Time Scheduler does not really make Linux an RTOS because in and of itself it does not provide kernel pre-emption - the ability for the kernel to interrupt kernel-space code to deal with incoming events that _must_ be processed. This is a requirement of a 'proper' hard-RTOS because such an OS must be able to guarantee a response time, and if it cannot interrupt kernel code the OS scheduler may be stuck waiting for kernel code to return before it can go on to deal with the input. The rtsched patches do appear to integrate with MontaVista's kernel pre-emption patches however, and together they would indeed form a proper hard real-time OS.

Kernel pre-emption does not come without a price though - it can make a significant dent in overall performance, and it is tricky to implement in a clean way, and this is why kernel pre-emption will probably stay out of the mainstream kernel for the forseeable future. It also isn't necessary for 99.9% of people, who, as long as the latency, the time to respond, is on average less than a few ms, are happy. This is called 'soft' real-time and is more than adequate for any video or audio work.

Linux is actually pretty bad at soft real-time as standard, with typical latencies around the 100ms mark, which is rather worse than any version of Windows 9x or NT, and a lot lot worse than BeOS, which has latencies in the sub-5ms realm. Andrew Morton's Low-Latency patches deal with this quite nicely, taking typical latencies down to the 1.5ms mark by improving various kernel algorithms and adding a few points where the kernel can reschedule itself during long periods in kernel-space code. This represents the best latency in just about any OS that does not do hard real-time with kernel pre-emption (QNX, vxWorks etc.) and does not hit performance in the way that pre-emption patches do.
What would be very interesting is to combine the low-latency patch with the improved scheduler in the rtsched patches...

As for GetRewted patches... well, I'm not entirely convinced about the value of a non-executable stack. The problem is whether they actually do any useful good - they give a warm fuzzy feeling of security while only actually preventing a limited subset of attacks. In addition, it's in the wrong place. It's a kernel-space fix for what is really a user-space problem - and certainly I think it's better to fix problems at source than patch them up elsewhere - otherwise you end up with code spaghetti.

My own personal favourite anti-stack-smashing add-on is libsafe, originally a Bell Labs project, which overrides dangerous libc functions with its own, safe functions, either by using the LD_PRELOAD feature of ELF shared objects to protect existing binaries, or by being linked in to a binary at compile time, preferentially to the existing libc functions. In addition, version 2 of libsafe now includes protection against format-string attacks that appear to be the new scourge of unix. Of course, the best place for this protection is in libc itself, and glibc 2.2 does include some protection like this, but it is a compile-time option only, and further, is primarily designed to help developers fix overflows during program testing rather than helping sysadmins in the wild - it causes more of a performance hit than libsafe does.

Anyway - as for 2.4.5, nice to see the VM is sorting itself out - I was that close to turning my desktop machine's ext2 partitions into UFS. I think I might convert them to ReiserFS now. :)