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.
1. Roland Piquepaille
2. It's just heap randomization, again.
Nothing to see here.
How we know is more important than what we know.
5...4...3..
Yippee-ki-yay
ACK NAK RST
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.
Offtopic but does anyone know what happened to Die Hard 4 (probably with a name like Die Hardest???). I read they were making it with Britney Spears as John McLean's daughter. Would of probably put me off one of my favorite movie series with her bad acting. I guess that was the answer to my own question!
:(){
I stopped reading after that first line.
Programming is not a matter of simply writing until things get full.
Microsoft helped develop a program to uninstall Windows?
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
If you watch Diehard, the movie, in your car DVD player running off a Sears Diehard battery while running DieHard on your laptop, does that mean you died hard 3 times over?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Funny how Mozilla crashed continually after enabling this software. I'm glad I don't go to UMass...
FTA:
""Today we have way more memory and more computer power than we need," he says. "We want to use that to make systems more reliable and safer, without compromising speed.""
I guess he hasn't tried Vista yet. Already out day; such is the industry.
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.
with the computer software industry and still confuses the word "hacker" with someone engaged in bad behavior has to be considered clueless.
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.
"Don't whiz on the Electric Fence!"
Still, programmers are privileging speed and efficiency over security, which leads to the famous "buffer overflows" which are exploited by hackers.
...Riiiight. Programmers are certainly privileging speed over security. That students are being taught nowadays that speed is the last thing you should care about, and that the inexplicable popularity of managed languages and so forth exists is completely irrelevant. And the combined losses in efficiency from many programs running at once causing things to run far slower than they have any good reason too...
I'm sure that the buffer overflows certainly aren't caused by programmers just not realising that they're there. There's no way programmers are that absent-minded.
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.
This was one of the smartest jokes I've read here in ages. If I'd only have some mod points...
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.
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.
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
"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...
metaphors, you have to understand them.
Back in the days when Memory was indeed in short supply, a decent programmer would use all sorts of tricks to reduce the overall memory footprint of the code.
It would often have the side effect of speeding up the code as well...
However, in these days of C#, Java etc, code optimisation seems to be a dying if not lost art.
IMHO, CS graduates these days do not understand the implications of the code they are writing. 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.
I asked the dev why this 'redundant' code was there.
His reply was that he had coded it as a single pass module and then later added the FOR loop controls. He had never been taught the costs in terms of CPU cycles the repeated recalculation of these unchanging values would have.
He said that they always left it to the compiler or runtime environment to sort out and anyway all Computers these days come with lots of RAM so who cares
Whereupon I proceeded to bang my head against a brick wall.
I 'optimised' the code for him. Then we compared the compiled code size (using the JAVA compiler) and mine was almost half the size of his.
so, we ended up with a module that was
1) Smaller (less memory used)
2) Faster (less CPU cycles used)
And probably most important, given the end customer of this code
3) More Maintainable (Easier for a human to read and understand)
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
"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
I haven't seen problems that would be solved by this application in years--I've been using Java.
The only reason left to choose C++ over Java seems to be some perception that it is significantly faster. Now you have a system that is tracking every allocation and deallocation you do. Heck, with Java's memory management there is absolutely no code run for 99% of the deallocations, so it's possible that Java-style memory management is actually quicker than a version of C++ that is almost as safe.
I'm not saying Java is the only answer, but for OO programming, Garbage Collected memory management is absolutely the only way to go.
"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?
On one hand you say that Die Hard is resiliant to random crashing due to double frees, etc. On the other hand, "It places guard pages around large chunks and frees such large chunks back to the OS (causing later references through dangling pointers to fail unless the chunk is reused)" - which encourages crashing. So, which is it? A bad-program crasher or a crash preventer?
Installed it, Firefox became unusable due to freezing up continually, removed it. Thanks anyway.
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....
DieHard was a virus bad in the 386 days. Funny how virus names become security names suddenly
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
then it's predecessors
"than its".
+1 Insightful
+1 Informative
-1 Obvious
---
+1 Total