>From: "Curt Sampson" <cjs@cynic.net>
> On Thu, 5 Sep 2002, James Santagata wrote:
>
> > As far a buffer overflows are concerned they are not the
> > only exploit that can be made nor necessarily the
> > most important.
>
> You still have to avoid them. Generally you spend a lot of money
> on this and still often fail completely to eliminate them. That's
> just the nature of C.
Sure, there are lot of things to avoid security-wise and it starts
with more than just the language selected. Depending on the app
and how it is deployed, you have to worry about the OS,
the webserver, the firewall, physical access to the datacenter,
human handling of passwords, etc. All of those issues have
many documented exploits. The point of all this is how much
will you spend in terms of cost, time to market, performance
and scalability to avoid one type of exploit by selecting a certain
language?
One of my friend's company makes high performance MPEG-4 media
servers. They written it in Java and it runs on MSFT server --
now you are asking how they are high performance, right? Me,
too. That's a double
performance hit. Mine is in C/mod_perl running on Linux and
BSD. It scales much, much better. My friend has told me, they
choose Java because of it's portability and support of SOAP.
They are getting demands for a Linux/BSD version, which they
have been working on for over 3 months. Well,
if it's so portable, why did it take 3 months to port and still has
not been released (rhetorical question - obviously lots of QA
regression testing needed as well)? Also, you don't need
Java to support SOAP. The concept behind SOAP is to
support web services while being agnostic to language
and transport protocol.
And will using Java solve or even mitigate any or all of these problems?
Even if Java is a more secure language than C or perl, a poorly
written program can just as easily or more easily be exploited
than a well written program in C or perl. That will never be changed.
Using Java to collect credit card data and then using HTTP rather
than HTTPS won't make the transaction any more secure.
If you are on NT and other MSFT OS's, there are a whole
slew of exploits, so trying to lock the windows with Java while
the doors remain wide open doesn't seem like it would do much.
Even BSD has had a number of exploits identified (and patched)
as well. Apache, too.
> And yes, a java program can allow exploits beyond this, just as a
> C program can allow exploits beyond this. But it's much easier to
> write Java without security problems than it is to write C without
> security problems.
>
> > Here are some 126 known Java exploits from CERT.
>
> Ha ha! I've seen more than 126 exploits due to buffer overflow in
> C code in just the last week. Try counting the number of those on
> the CERT web site.
Again, are you selecting Java soely for security? If security was such
a consideration for Java, Sun has really done some poor marketing
by stressing it's so-called portability of "write once, run anywhere"..
> All your points are true, but that still doesn't change the fact that
> the vast majority of security holes due to bugs in code in systems over
> the past few years have been buffer overflows. And a *lot* of money has
> been spent on patching systems because of this. That's all.
And my further point is that using Java for your apps isn't going to
solve the buffer overflows that have been found in Microsoft OS's,
various JVMs, BSD and Apache to name a few items. In those cases,
Java will give you a false sense of security and at the same time, you
would be selecting a language to solve one issue and perhaps not
be considering time to market, cost, performance and scalability.
Java may be the right choice and it may not. It depends on many
factors and issues, but Sun has done a fabulous job of
positioning Java as the best choice that you write once, run
everywhere, when often neither of those are true.
James Santagata
A U D I E N C E T R A X
http://www.audiencetrax.com
Received on Fri Sep 6 19:46:06 2002