Slashdot Mirror
DieHard, the Software
Roland Piquepaille writes "No, it's not another movie sequel. DieHard is a piece of software which helps programs to run correctly and protects them from a range of security vulnerabilities. It has been developed by computer scientists from the University of Massachusetts Amherst — and Microsoft. DieHard prevents crashes and hacker attacks by focusing on memory. Our computers have thousands times more memory than 20 years ago. Still, programmers are privileging speed and efficiency over security, which leads to the famous "buffer overflows" which are exploited by hackers."
Along the same lines anyway... a new feature in Vista: Address space layout randomization (ASLR) is a computer security technique which involves arranging the positions of key data areas, usually including the base of the executable and position of libraries, heap, and stack, randomly in a process' address space. http://en.wikipedia.org/wiki/Address_space_layout_ randomization
I thought DieHard was a random number generator test suite. It is annoying when people dont even look around for other programs with the same name and do similar things.
"Still, programmers are privileging speed and efficiency over security..."
Speed and efficiency of *development*, maybe.
Which is the problem. Modern software is so dependent on toolkits and compiler optimizations and various other "pre-made" pieces, that any program of even moderate complexity is doing things that the programmer isn't really aware of.
No, putting arrays on the stack causes buffer overflows. Which is trivial to not do, and trivial to check for.
The fact that Microsoft doesn't HAVE a security model, IE/Outlook are jokes, and users run as admin has a bit more to do with it.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
If you were somehow to install DieHard software on a DieBold machine, does the universe collapse in on itself? This is one of those pasta plus antipasto situations, I think.
Yeah, its coming out soon, its going to be called "Live Free or Die Hard". I saw a trailer for it before "The Good Shepherd", though all I can tell you from that is that there will be a lot of big explosions and car chases.
Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination.
You should never program thinking about security issues.
Write the algorithms correctly and there won't BE any buffer-overflows.
What's so hard about this?
I don't know the meaning of the word 'don't' - J
Well thank god we have Vista to fill up that uptapped goldmine!
Wouldn't using languages like Lisp do basically the same job? I mention lisp, besides it being a favorite language of mine, because I know the end product can be coded/compiled fast and efficiently while maintaining security in many cases. Other more popular languages like Python, while getting more lispish, seem to have a inherent speed penalty that cannot be reduced as easily come compile time though I am not sure, saying this as more of a spectator to that language.
Note: I'm sure other functional languages can do the job of memory management and protect from buffer overflows as well as Lisp, I'm just no expert on them so I can't speak for them.
It's just that over the years, I have seen products come out for C family of languages that protect the programmers from the trickiers parts of C..... which seem to come up again and again even for expert programmers and where there is no bulletproof solution. I'd want to know if another language wouldn't do the job in 90% of the cases.
There is nothing wrong with putting an array on the stack. I once had the need to copy a function into a local int[50] and run it from there - no issues (embedded system, the function needed to run from RAM). The problem is when people write code that can blow right past the end of an array. They don't stop to think that the functions they call to dump data in there don't know where the end of the available space is. Oh right, the data told me how much space to allocate and I just allocated that much and read until EOF. ;-) ok, that's a heap (not stack) buffer overrun. Anyway arrays on the stack are not inherently bad.
Firefox 2 crashed for the first time ever (I've used it since beta 1 came out) for me today... suspiciously, less than five minutes after I turned DieHard on. Hrm.
Am I wrong in thinking this is just another implementation of systrace?
http://www.citi.umich.edu/u/provos/systrace/
It is called WindowsXP. When I kill it on a regular, daily basis, its Dies Hard.
Even assuming nobody wants to go to all that trouble, there are solutions. ElectricFence and dmalloc are hardly new and far from obscure. If a developer can't be bothered to link against a debugging malloc before testing then you can't expect their software to be immune to such absurd defects. A few runs whilst using memprof isn't a bad idea, either.
This assumes you're using a language like C, which is not a trivial language to write correct software in. For many programs, you are better off with a language like Occam (provided for Unix/Linux/Windows via KROC) where the combination of language and compiler heavily limits the errors you can introduce. Yes, languages this strict are a pain to write in, but the increase in the initial pain is vastly outweighed by the incredible reduction in agony when debugging - if there's any debugging at all.
I do not expect anyone to re-write glibc in Occam or any other nearly bug-proof language. It would be helpful, but it's not going to happen.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
It would probably mean that you died hard with a vengeance.
You can hold down the "B" button for continuous firing.
Ada's been doing that kind of runtime checking and throwing exceptions for 20 years now without needing a VM to enable exception handling.
wow, someone who gets my commentary on british politicals, brilliant.
How we know is more important than what we know.
"Don't whiz on the Electric Fence!"
In reading this article, I started to wonder a lot about this. writing to conserve memory is a bad thing? I will say that I haven't noticed that in most software, regardless of whether it's OSS or closed-source. If anything, there seems to be a variation of Parkinson's Law in effect. Yes, computers these days have a lot more memory available, however, the number of applications and the size demands of each application has grown almost in lock-step with that. 15 or so years ago, yes, you had one OS and one application running - maybe, if you were lucky or were running TSR apps, two or three. These days, the OS takes up a hefty chunk, and it's not uncommon to see 8 or 9 (if not more) applications running at once. What they all seem to have in common is that they assume they have access to all the RAM, or as much of it as they can grab.
I have to wonder if he's actually looked at things these days. I don't see where programming (properly done) to conserve memory is a bad thing. If anything, it seems that few are actually doing it.
"Portable" can mean that it runs on more than one PC-type platform, or that it can also run on handheld platforms with small CPU, RAM, and battery. True, there's J2ME, but it's hard for an individual in North America to buy a device to run midlets that isn't locked down in some way by the operator of a mobile telephone network. There's a reason that GBA games are written in C and that Nintendo DS games are written in C++ and not Java.
I did a quick read of the whitepaper and sort of see it as heap randomization+. I have very little faith in the claims of low overhead. But leaving that aside, there are 2 major problems here:
1) If there is a program crash, it may be possible to reproduce the bug on the same computer, but probably not on 2 different ones, such as the user's and the developer's.
2) It discourages programmers from good design and thorough testing by leading them to believe that bugs won't occur.
The claim for DieHard (from the whitepaper) is that it "tolerates memory errors and provides probabilistic memory safety". But bugs will still happen! I once added about 10 lines of code to log a bug our team was having a hard time tracking down. It turned out to have its own bug that would be hit if:
- Two threads were accessing the same buffer
AND
- One of them was swapped out during the execution of 3 machine instructions (out of about a million)
It took my moderately sized customer base 2 weeks to hit it. The only way to avoid memory errors is to make the code bulletproof, which means fixing it when bugs are reported.
Methodologies for writing secure code have been known for decades. A far more interesting article would be one that attempts to discover or explain why certain engineers and organizations refuse to use them, or, for that matter, why they refuse to learn them in the first place.
Note: there are new breeds of software developers who do NOT buy into the old-school lines of bullshit that have brought us where we are. Hopefully, these smarter heads will prevail as we move forward.
Die Hard 4 - going commando.
clueless is thinking you can reclaim the meaning of a word once a new definition becomes common usage in a larger world
I should probably clarify that I can't be 100% sure DieHard was the problem, but I still think it's possible. Sadly I can't reproduce the error (not surprisingly, given DieHard's random nature). Although given the sheer volume of drivers and apps interacting on this comp, which still manages to stay stable normally, it's surprising DieHard didn't bring my whole house of cards down instantly. :)
The worst bugs are the ones that are hard to reproduce. In fact, when faced with a bug that's difficult to reproduce, I've been known to quip "yet another unintentional random number generator". The suggestion that they're going to apply a pseudo-fix that involves random allocations raises all kinds of red flags. I'd much rather have fine-grained control over which sections of code are allowed to access which sections of memory, and be able to track which sections of code are accessing a chunk of memory. I'd much rather have strict enforcement of a non-execute bit on memory that's only supposed to contain data (there is some support for this already). Introducing randomness into memory allocation? Worst. Idea. Ever. It's like throwing in the towel, and if they put that in at low levels in system libs and things like that, we're screwed in terms of every being able to *really* fix the problem. If their compiler is going to link against an allocator that has this capability, I hope they provide the ability to disable it.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
These techniques are old hats: several malloc implementations offer randomization, and ElectricFence finds pointer errors by spreading out and aligning allocations across virtual memory.
In practice, however, a decent set of test cases together with valgrind will make any of those runtime gymnastics unnecessary.
At a 50-75% memory usage increase no less.
Die Hard 5 - Hardly Dying
*pSig = NULL;
Basically almost every point you raised can be addressed simply by saying "get your head out of five years in the past". Moderm GC can take little overhead, and will run when needed even with the CPU being consumed.
Swing does not really have the problems you speak of any longer, if you are using it right... heck, it didn't really have those problem to any great degree about seven years ago when I was building a large custom client app all in swing for only desktop deployment.
Complaining about the build system is like saying GCC has a bad build system - really it has no build system, and you should use something made for building Java. That is why we have Ant and the like...
Of the remainder, I really only think #7 has much in the way of merit. Have you looked into the java.nio package? This makes working with binary data much simpler...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
God, no! Disco Bandit for life. I called myself a "Senator" and gave all my pets names that started with Intern. I miss that game sometimes.
"programmers are privileging speed and efficiency over security..."
This comment, at least the way I read it, is actually rather language independent. It has to do with programmers writing bad code in the first place. It has to do with them using variables that are too small to hold what they need to hold. Other bad practices is allowing users to define what goes into a variable, but then not validating the user input to make sure it is a valid and nonerroneous input. Most programmers nowadays are just being taught to just write an error handler for the basic stupid shit that may happen, instead of just writing a handler to prevent stupid stuff from ever causing an error in the program in the first place, which brings why the parent post mentioned java, as it has better erroneous variable control then it's predecessors.
However i again mention that it is language independent, and it's more bad programming practice then anything.
You never realize how much manually made unmanaged "linked" lists suck, till you have src.link.link.link.link...
From the link i see my original post was very on topic (ish...). It seems the movie is about internet terrorists shutting down the USA. Obviously because we a insecure coders! (And yes, you get none of that from the trailer.)
:(){
metaphors, you have to understand them.
http://www.avira.com/ is picking SPR/Hook.MadTool.B signature in C:\WINDOWS\system32\madCHook.dll file.
The Answer Lies in The Genome
BTW Do not install this crap... I do software development and this program has made it impossible to compile/run my programs (even after I uninstalled it) and also while it was running it would not allow Eclipse to run. So basically this program screwed me over big time. I am writing a database that is is to be deployed tomorrow morning. **&**&**&*&* ..... Note to self: Do this crap in a virtual machine and not while developing a program.
I don't think it's typically the programmers fault that there are security issues with the software. If the programmer was taught how to do things properly, then they would do things properly. Also, if they weren't so rushed to get a product out the door, they would be able to do a proper review and test of the code and find a majority of the bugs before the product hits the streets (or the server room in the case of custom software)
Typically, a programmer is doing their job. The programmers manager is doing their job, by squeezing the work and deadlines of the programmers.
My $0.02 CDN
"Well you're not Fiona Apple, and if you're not Fionna Apple, I don't give a rat's ass."
-- Chaos, panic, pandemonium... My job here is done!
the film "live free or die hard" is on it's way. The synopsis alone makes me wanna gag..
http://www.imdb.com/title/tt0337978/
When a criminal plot is in place to take down the entire computer and technological structure that supports the economy of the United States (and the world), it's up to a decidedly "old school" hero, police detective John McClane (Willis), to take down the conspiracy, aided by a young hacker (Long).
every day http://en.wikipedia.org/wiki/Special:Random
Not sure what the typical mass of a star is meant to be...
However, using Sol (and our solar system) as an example,
anything within an order of magnitude will no longer be a planet.
I think you need at least two orders of magnitude difference
for a "well defined" orbit.
(end of pointless information, now returning to your regular Slasdot)
"DieHard is a piece of software which helps programs to run correctly and protects them from a range of security vulnerabilities." Isn't that what the operating system is for? Why is there such a huge market for third-party products that compensate for the shortcomings of unstable and insecure software. If you paid once for the OS and the software, why should you have to pay again for third-party applications to secure them? Doesn't make sense to me.
Why not just license under the GPL, LGPL or some other open source license? This business of being "free for non-commercial use" restricts users who use open source software for commercial purposes. This software is really "non-free" according to any definition of the FSF or Open Source Initiative, which explicitly forbid discrimination against fields of endeavor. Perhaps you should say "non-free, but gratis for non-commercial use."
A rare voice of sanity, thank you.
from the plan 9 fortune file :
Almost all good computer programs contain at least one random-number generator.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Mozilla crashed for me as well... then I uninstalled it.
"DieHard is a piece of software which helps programs to run correctly and protects them from a range of security vulnerabilities. " So it's basically a Tron program?
Installed it, Firefox became unusable due to freezing up continually, removed it. Thanks anyway.
IMHO, CS graduates these days do not understand the implications of the code they are writing.
IMHO, lots of programmers today don't understand the power of the tools they use.
For example...
I did a code review a few months ago where in one place that was inside a FOR Loop, there was a lot of statements that always returned the same values and never used any of the values that changed between iterations of the loop.
Did you try compiling it and looking at the resulting code? Most modern compilers automatically perform an optimization called loop-invariant code motion, which takes that stuff that does the same calculation on each iteration and only runs it once at the start.
Today's computers have more than 2,000 times as much memory as the machines of yesteryear, yet programmers are still writing code as if memory is in short supply.
I stopped reading after that first line.
Yeah, it was pretty dumb. I mean, we've been building digital computers for over 50 years now. You'd have thought by now that we'd have written all the software we'd ever want, right?
No. We keep writing new software because we're doing new things that older computers couldn't do. That means that all that memory is necessary, because otherwise the application we're working on would have been written 20 years ago.
No, that's what OpenBSD does. Sorry for any ambiguity -- that whole paragraph was about OpenBSD.
-- Emery Berger
If so, it's essentially irrelevant for my purposes...
"Not an actor, but he plays one on TV."
If you look back up through the stories you can see that others have reported problems. Programs which have workarounds for memory problems rather than actually fixing them (read: Mozilla and descendants) may be likely to fail when running in this environment. Whoever marked this guy as a troll is a) an idiot and b) should have their moderation powers taken away permanently for not familiarizing themselves with the material before moderating.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I don't know of any case where a memory leak can be considered user error so saying "you have to use it right" sounds pretty fishy to me.
Um, I recommend to you reusable code modules. In any language.
At least 90% of that 90% should be implemented as library routines.
Back in the day we talked about OTL and RTL, before the black ships came and we lost the secret of hose gartering that never ravels, er, but I digress...
% sarcasm = `{hget 'http://slashdot.org/comments.pl?sid=214522&cid=17 431396' | grep comment_body_17431396 | sed -E 's/<[^>]+>//g'} /env/sarcasm
% cat
and I thought Perl was the king of write only code
%
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Users do not "use" swing directly, they use application written using the Swing API. So by saying "you have to use it right" means you have to be careful to use the API correctly, or at least you used to. The swing app we wrote did not have memory leaks, it was meant for standalone desktop situations to be running at long stretches. We used a number of profilers extensively (including HAT) to figure out where memory leaks were coming from, and shut them down. Most people who think Swing leaks memory are probably not realizing some memory leaks are their own fault. People too often think that just because you have a GC, you need not be concerned about memory but it's just not the case.
Java 1.5 features like weak references helped provide support for mechanisms to address a number of common programming patterns that lead to memory leaks, this is why I noted that the complaint was probably not against any modern version of Swing.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I fully agree with you to the extent that it would be a grave error to attach the Diehard or simlilar thing to software under development. We would never know where we are.
A few weeks ago I had one of the worst bugs I had ever encountered in a decade of C/C++ programming. Something was overwriting the end of a buffer in a multithreaded program where each thread used the same algorithm, processing different data. Thankfully, the bug was reproducible under a complex setup of inputs, but for a long time I could not be certain which element in the series of test data was causing the problem, or why it caused it, or even in which thread it happened. In the end, it took quite some time to solve the problem. Rather than being in the new code, it was in a module that I suspected the least since it had been running in the field for over a year with no problems. It turned out that I had made a bad assumption about the data that would enter that buffer - assuming (for good reasons) that it would always be some multiple of 8 bytes. I was doing some assembler language processing of that data in this module that realized a significant optimization based on this assumption. The thing was, it turns out in the end that there are some potential generators of that data that just don't behave the way I expected. Fortunately they had never been encountered yet in the field. By luck rather than design, my test setup included such a generator.
This leads me to my conclusion: We must always follow best practices and do proper testing. Then, when all is properly done and ready ship, I don't think it would hurt at all to recompile with the Diehard system or something similar, as an insurance policy against unforeseen circumstances.
Shouldn't Microsoft use this software on their own products to fix these types of problems?
The day Microsoft creates a product that doesn't suck, it will be known as the Microsoft Vaccuum Cleaner!
Perhaps the reason we endure so many buffer-overflow exploits and need stopgaps like DieHard is because too many mediocre programmers were playing with "dangerous" languages like C(++)? No rules and no boundaries leads to bad behavior... every parent knows this. Too bad IT project managers never figured that out....
I did and I never looked back. It is a damm lot easier then trying to fix the deficiencies of a speed, speed and only speed focused language (C/C++) by the means of tool.
I tried [2] - and it did not work well. A add-on tool just can not beat build in buffer overrun protection by no means.
In the case of Splint static analysis is just not enough, you need runtime checks as well.
And in the case of Die-Hard all the protection bolted on later at runtime. And that will relay be great for performance.
Only
$360,000 wasted because the majority of programmers are to lazy to learn a new programming language (those present are of course not meant).
Or there bosses rather buy a tool then a course for them.
Martin
PS: If you like to try Ada you get the free and open source version here [3].
[1] http://en.wikipedia.org/wiki/Ada_(programming_lan
[2] http://en.wikipedia.org/wiki/Splint_(programming_
[3] https://libre2.adacore.com/
The System 360/370 series, and their successors, solved the "memory overflow" problem decades ago by a combination of hardware and OS architecture. Each page of real storage in hardware has a "storage bump" containing, along with the recently-used bit that enables paging, a storage key. Programs do not allocate memory - instead they make OS calls and the OS allocates memory. It allocates this memory in the key of the program being executed, usually. OS and system-level programs execute in keys 0-7, and non-OS programs execute in key 8. Things like communication buffers and the like are allocated by system functions, not by your application program; and if your key 8 program tries to store into a key 0-7 area without calling some authorized system function to do so, your program is terminated. This mechanism prevents a lot of malicious stuff from happening because you cannot generally store into any OS-related areas. You can, of course, modify your own program via array overflows or whatever, but depending upon various ways you bound / linkedited your program that also could get it killed. I doubt that the current set of applications in Windows world will allow migration to the above kind of architecture on Intel hardware - but the example is there for any who want to follow it.
Sad that our posts are at the bottom so almost no one will see them. I posted almost the same before I saw your post. Only I suggested Pascals more powerful sister [1].
g uage)
But anyway: they will just continue to produce new tools to fix the deficiency if C/C++ so programmers won't need to learn new languages, or because hirering will be easier.
I have not much hope for the software developing industry.
Martin
[1] http://en.wikipedia.org/wiki/Ada_(programming_lan
No conserving memory or CPU cycles is not bad - but you have to strike a balance between that and safety, security, reliability. And C and it's successor C++ have got that wrong - especially now where almost every computer is wired to the internet.
g uage)
If you look at the great language shootout [1] then you will see that i.E. Ada [2] uses only marginally more memory or CPU cycles but it offers a lot more on the safety, security, reliability part.
As for Die-Hard: From what I read it is going to be a lot more wastefull on memory or CPU without delivering what Ada can do.
Martin
[1] http://shootout.alioth.debian.org/
[2] http://en.wikipedia.org/wiki/Ada_(programming_lan
I am possible one of the programmers who know C++ really in deeps. And yet there was allays room for surprise as the Ruby community would call it. Up to the point that I decided that C/C++ are not the right tools and I switched to Ada [1].
g uage)
:-).
C and C++ are so focused on speed - speed of execution and speed of code hacking:
If:
signed x;
unsigned y;
why must
x = y;
be allowed? I mean you will need:
x = (signed)y;
but do you really need that quick hacking shortcut which is difficult to maintain and may hide a book.
And here comes the "NO" part: Most programmers are not allowed to choose there programming language.
Martin
[1] http://en.wikipedia.org/wiki/Ada_(programming_lan
PS: Yes I am a bloody Ada advocate who plasters this discussion with damm Ada links