Java flaw could lead to Windows, Linux attacks
- Thread starter DnetMHZ
- Start date
VirtualLarry
No Lifer
- Aug 25, 2001
- 56,587
- 10,227
- 126
Security is a process, not a product. However, getting rid of buffer overflows would eliminate over 80% of CERT alerts and the vast majority of the largest impact malware.
Heh.
Just remember too that buffer overflows are just a popular thing right now. Why? Because all of the legacy code left in OS's today from years ago and the fact that buffer overflows can be detected thru brute force means. So it doesn't take any thought to find a buffer overflow flaw...
Buffer overflows are just a easy target, it doesn't mean that when you eliminate buffer overflows it will automaticly make your software more or less secure! For every screw up with the memory stack that a programmer makes there are a thousand other flaws that exist in software. It may eliminate 80% of current exploits, but it doesn't mean that the amount of flaws that wil be discovered will decrease by any appreciable amount in the future.
Oh, well. Anything can help.
Just remember too that buffer overflows are just a popular thing right now. Why? Because all of the legacy code left in OS's today from years ago and the fact that buffer overflows can be detected thru brute force means. So it doesn't take any thought to find a buffer overflow flaw...
Buffer overflows are just a easy target, it doesn't mean that when you eliminate buffer overflows it will automaticly make your software more or less secure! For every screw up with the memory stack that a programmer makes there are a thousand other flaws that exist in software. It may eliminate 80% of current exploits, but it doesn't mean that the amount of flaws that wil be discovered will decrease by any appreciable amount in the future.
Oh, well. Anything can help.
Buffer overflows were one of the main attack vectors of the Morris worm, which took down the net in 1988. They were well known before the worm, and have been a major security issue for decades.
Run a static analysis tool against a large source code base of a real project, Then after you've sorted through thousands to millions of warnings of potential problems to find the actual exploitable buffer overflows, tell me that it didn't require any thought.
I also see current programmers making buffer overflow mistakes at about the same rate programmers always have, so I don't think they're primarily the fault of legacy code.
While it doesn't eliminate all vulnerabilities, reducing the number of vulnerabilities does make your software more secure. You've got to start reducing vulnerabilities somewhere and buffer overflows are a good place to start.
In my experience auditing software, your numbers are completely off. In C/C++ where such flaws are easily made, the ratio of buffer overflows to other flaws is often higher than 1:1, instead of being much less as you suggest above. However, it's true that with the typical existence of 2-3 security errors per kLOC on average that reducing the number of flaws by 50% (as my experience suggests that eliminating buffer overflows will roughly do in C/C++ code) still leaves many vulnerabilities to discover.
My point wasn't about maximum numbers of potential problems that exist, I was talking about maximum numbers of potential problems that are FOUND by malicious coders/crackers/whatever.
Buffer overflows are found because that's what they are looking for. They are relatively easy to find, all it requires is some clever brute force technics and a few days of computer time and you can probably find a buffer overflow in any c/c++/whatever program of decent size.
It's not like they have all the time in the world to find these things, they just go with the easiest way and once they find it they have to figure out how to exploit it.
If buffer overflows are eliminated for ever and ever they'd just change their focus to other problems and they will still find problems probably close to the same rate. If it's not one thing it's going to be another.
Buffer overflows are found because that's what they are looking for. They are relatively easy to find, all it requires is some clever brute force technics and a few days of computer time and you can probably find a buffer overflow in any c/c++/whatever program of decent size.
It's not like they have all the time in the world to find these things, they just go with the easiest way and once they find it they have to figure out how to exploit it.
If buffer overflows are eliminated for ever and ever they'd just change their focus to other problems and they will still find problems probably close to the same rate. If it's not one thing it's going to be another.
That may be true, but it's not a reason to not solve buffer overflow flaws. Getting to the state where most software is secure is going to be difficult and take time, as there's no single solution for security issues. While secure requirements and design are essential, there will nonetheless be flaws in implementations of the best of designs.
If you aren't doing low level OS/hardware coding, why take the additional risk of using C/C++ for the implementation? If you love C too much, check out Cyclone, C Cured, or D for a safer version of C.
Yes, the JVM has some problems, but compare it to downloading C/C++ code to your system. The attacker doesn't need any security flaws in that case; they already have access.
OpenBSD's libc has some additional calls or whatever that help cut down on issues. One of the problems with using something like JAVA is that it is only "natively" available on a small number of platforms.
OpenBSD is a good example of using multiple solutions: static code analysis to remove unsafe calls from the OS, randomization of the memory space to make exploits likely to fail, privilege separation, and much more.
I'm not sure what you mean by Java only being "natively" available on a small number of platforms though.
If you go to sun's java site to download the JVM and whatnot, your selections are pretty slim. IIRC it's Linux x86, OS X, and Windows. No Linux on other archs, or *BSD on any arch.
So if you are looking for ultimate portability, you probably have to go with an interpretted language (which can often fail to the same problems compiled languages can) or C/C++.
That was my only point.
kamper
Diamond Member
- Mar 18, 2003
- 5,513
- 0
- 0
Originally posted by: n0cmonkey
If you go to sun's java site to download the JVM and whatnot, your selections are pretty slim. IIRC it's Linux x86, OS X, and Windows. No Linux on other archs, or *BSD on any arch.
So if you are looking for ultimate portability, you probably have to go with an interpretted language (which can often fail to the same problems compiled languages can) or C/C++.
That was my only point.
Sun Java also runs on sparc architectures (duh!) and will obviously run on solaris systems. Given that, it can probably be modified to run on most unix systems without too much trouble. Of course, since it isn't open you might not find a Sun vm to do that but it is possible to implement your own. IBM makes one.
About the portablility thing, people misinterpret the idea of java being "so" portable. No one ever claimed you could get java to run on more systems than any other language. The point is that, once it has been compiled, you can run it on any system with a compatible virtual machine without recompiling. The original inspiration for java was a platform where different machines could share executable code over the internet. You see that with applets in browsers and to a smaller degree with some distributed systems.
Originally posted by: kamper
Originally posted by: n0cmonkey
If you go to sun's java site to download the JVM and whatnot, your selections are pretty slim. IIRC it's Linux x86, OS X, and Windows. No Linux on other archs, or *BSD on any arch.
So if you are looking for ultimate portability, you probably have to go with an interpretted language (which can often fail to the same problems compiled languages can) or C/C++.
That was my only point.
Sun Java also runs on sparc architectures (duh!) and will obviously run on solaris systems. Given that, it can probably be modified to run on most unix systems without too much trouble. Of course, since it isn't open you might not find a Sun vm to do that but it is possible to implement your own. IBM makes one.
About the portablility thing, people misinterpret the idea of java being "so" portable. No one ever claimed you could get java to run on more systems than any other language. The point is that, once it has been compiled, you can run it on any system with a compatible virtual machine without recompiling. The original inspiration for java was a platform where different machines could share executable code over the internet. You see that with applets in browsers and to a smaller degree with some distributed systems.
I can't believe I forgot Solaris.
I understand the point on portability. C is portable one way, JAVA another. Either way one of the points is to make a portable application.
We're "stuck" with C/C++. There's just no way to get support for all of the various architectures/OSes out there without using something like C.
I'm not sure why you think that. Most popular languages are available for almost every platform. The GNU Compiler Collection, gcc, compiles code for all of its languages, which include Ada, FORTRAN, Java, and Objective C in addition to C/C++, for all of the dozens of platforms it supports. Well known non-gcc languages like Haskell, OCaml, Perl, Python, Ruby, Scheme, Smalltalk, and SML are available for pretty much any UNIX, Linux, and Windows. In fact, C source code is often less portable because of the language's small set of libraries, requires you to modify much of your code for different operating systems, hence projects like the Apache Portable Runtime to make C easy to port if it's coded against the APR API instead of the native OS API.
Can you run that JAVA code without a JVM or anything?
I don't acknowledge Ada as a language because I would lose friends.
I don't think Fortran gets used a whole lot, and besides Apple no one uses objective c.
I don't believe most of those non-gcc languages are low level enough to code an OS in without losing a lot of performance.
Yes, there are Java compilers that compile Java to native machine code. I believe gcj does it for the GNU compiler collection. There are interpreted versions of C too.
Well, I'm with you about Ada, but I can't be too outspoken about it or I'd lose friends myself. ;-)
FORTRAN is still huge, and FORTRAN 90 and 95 are even object-oriented!
And if NeXT could take over Apple with objective C, who knows where they'll strike next?
The functional languages like ML and Scheme are very competitive with C these days in terms of performance, and generally better than C++. However, you're likely right about perl, python, and ruby, though I did see a UNIX system once where everything above the kernel and libc was perl: init, daemons, shell, everything.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 24K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter