Re: It's Time to Abandon Insecure Languages

[Greg Broiles]

At 12:50 PM 7/22/2002 -0400, [EMAIL PROTECTED] wrote:

>CERT is far from a comprehensive source of security bug reports. Does
>anyone have statistics of bug types for Bugtraq or Mitre's CVE?

The CVE data is available at ;
a mechanical (e.g., string-based) search of the database for all reports
(2224 as of the data set from June 25, 2002) find 461 which mention the
string "buffer overflow" in their description.

For the 563 reports dated in 2001, 99 mentioned buffer overflows.

For the 88 reports published so far in 2002, 21 mentioned buffer overflows.

But - the CVE web pages specifically warn, "CVE is not designed like a 
vulnerability database, so searches for general terms like "Unix" or 
"buffer overflow" could give you incomplete or inaccurate results."


--
Greg Broiles -- [EMAIL PROTECTED] -- PGP 0x26E4488c or 0x94245961



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[Victor.Duchovni]

CERT is far from a comprehensive source of security bug reports. Does
anyone have statistics of bug types for Bugtraq or Mitre's CVE?

I get daily bug reports via FS/ISAC. Most of these are not
sufficiently severe or broadly applicable to be CERT advisories. These are
mostly application logic issues, but the evidence is I must admit
anecdotal. I don't have survey results.

-- 
Viktor.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[John S. Denker]

[EMAIL PROTECTED] wrote:
> 
> This is more indicative of CERT's focus than the relative frequency of
> security issues. The fact that a large fraction of e-commerce merchants
> let you set the price for the goods you buy is in practice a larger threat
> than the widely publicized buffer overflows.
> 
> Semantic security bugs in individual web sites do not rate highly enough
> on Cert's seismograph, but are in practice far more common.

Interesting..

Earlier he wrote
> Most security bugs reported these days are issues
 
> with application semantics

We are talking about _reported_ bugs.  If CERT is not the 
right place to look for reports, please tell us where we
_can_ find appropriate reports.

I was trained as a scientist.  I like to look at data.
Listening to other people's summaries and conclusions is
nice, too, but sometimes it pays off to take a look at 
the real data.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[Victor.Duchovni]

This is more indicative of CERT's focus than the relative frequency of
security issues. The fact that a large fraction of e-commerce merchants
let you set the price for the goods you buy is in practice a larger threat
than the widely publicized buffer overflows.

Semantic security bugs in individual web sites do not rate highly enough
on Cert's seismograph, but are in practice far more common.

> My evidence:  http://www.cert.org/advisories/
>

-- 
Viktor.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[John S. Denker]

[EMAIL PROTECTED] wrote:
> 
> Most security bugs reported these days are issues
> with application semantics (auth bypass, SQL injection, cross-site
> scripting, information disclosure, mobile code execution, ...), not buffer
> overflows. 

Really?  What's the evidence for that?
What definition of "most" are we using?
One out of 20 doesn't count as "most" in my book.

When I look at the reports for 2002 year-to-date, at 
http://www.cert.org/advisories/ there are 20 advisories.  
Depending on how you count multi-bug reports, it appears that 
19 out of 20 involve buffer overflows and related issues -- 
things that could easily be prevented by using a language that 
has a built-in string type and automatic object management.
Exotic languages are not required;  C++ would make a huge
impact.  And of course in any language a modicum of skill and
care is required;  it's hard to make a language foolproof 
because fools are so ingenious.

My evidence:  http://www.cert.org/advisories/ 

20- multiple, including writing out-of-bounds
19  buffer overflow
18  multiple, including buffer overflow
17  stack overflow
16  multiple, including stack overflow
15= DoS: internal consistency check
14  buffer overflow
13  buffer overflow
12- format string
11  heap overflow
10- format string
 9  multiple, including buffer overflow
 8  multiple, including buffer overflow
 7- double free
 6  multiple, including buffer overflow
 5  multiple, including heap overflow
 4  buffer overflow
 3  multiple, including buffer overflow
 2  buffer overflow
 1  buffer overflow

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[Victor.Duchovni]

False sense of security. Most security bugs reported these days are issues
with application semantics (auth bypass, SQL injection, cross-site
scripting, information disclosure, mobile code execution, ...), not buffer
overflows. Only languages that operate on semantic specifications stand a
chance, and even then the specification could be wrong or incomplete...

-- 
Viktor.

On Sun, 21 Jul 2002, Arnold G. Reinhold wrote:

> Language wars have been with us since the earliest days of computing
> and we are obviously not going to resolve them here.  It seems to me
> though, that cryptographic tools could be use to make to improve the
> reliability and security of C++ by providing ways to manage risky
> usages.
>


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[Arnold G. Reinhold]

Language wars have been with us since the earliest days of computing 
and we are obviously not going to resolve them here.  It seems to me 
though, that cryptographic tools could be use to make to improve the 
reliability and security of C++ by providing ways to manage risky 
usages.

I have in mind a modified development environment that detects 
dangerous programming instances like pointer arithmetic,  assignments 
in "if" statements, C (as opposed to C++) strings, char array 
declarations, maloc's etc.  Methods where such usage is necessary 
would be signed by the author and one or more reviewers, with the 
signature embedded inside a special comment statement.  The 
development environment would then check whether only approved usages 
are present and, if so, sign the executable file. Final versions of 
code would be built on trusted servers whose compilers could not be 
tampered with and whose private key is not accessible to the 
developers.

Implementing such an environment should not be difficult. No real 
language changes would be involved, beyond reserving a standardized 
comment prefix for signatures. Most programmers would only be able to 
employ safe objects and constructs.  The few instances where 
dangerous usages were really needed would be limited, visible and 
require authorization.

Arnold Reinhold

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[bear]

On 18 Jul 2002, Pete Chown wrote:

>If you want totally type safe languages that use ahead of time
>compilation, look at Eiffel, Sather, the Bigloo Scheme compiler, and so
>on.  Also don't forget gcj, which does ahead of time compilation for
>Java with the same type checking that you get in the "managed
>environment".

Agreed.  And I particularly like Scheme.  However, it's also not
hard to compile your C code with bounds checking turned on if you're
willing to sacrifice maybe a few things you shouldn't be using anyay,
so it's pretty inexcusable IMO to still be having buffer overflows.

Bear


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: It's Time to Abandon Insecure Languages

[Pete Chown]

> eWEEK July 8, 2002
> It's Time to Abandon Insecure Languages

> The security of the internet took a one-two combo to the gut ...

Ugh, looks like the English language did too. :-)

> These holes
> demonstrate that we must switch to writing security-sensitive code in
> managed environments, like the Java virtual machine or .Net run-time, that
> continually enforce code/data distinctions.

This is nonsense, you don't need a managed environment to get type
safety.  Pascal was being compiled ahead of time for years before Java
was ever thought of.  (You can break type safety in Pascal, but you have
to make an effort.)

If you want totally type safe languages that use ahead of time
compilation, look at Eiffel, Sather, the Bigloo Scheme compiler, and so
on.  Also don't forget gcj, which does ahead of time compilation for
Java with the same type checking that you get in the "managed
environment".

> We have to get over the bias that there's something dishonorable about
> choosing languages that prize safety over pure efficiency.

This I can agree with.  On the other hand I don't see Java as a language
that emphasises safety.  It may have type checking, but it has inherited
a lot of obscure syntax from C.  Remember, we aren't just interested in
avoiding type errors.  We have to reduce the overall bug counts, because
there are plenty of security holes that don't result from typing
problems.

It would be better to look at Eiffel (or Ada if you really must, but
personally I don't like it).  Eiffel has a Pascal-like syntax which is
more verbose than Java, but more readable.  You have to type a bit more,
but you don't waste hours debugging because you wrote "=" instead of
"==".  It has a few other special features to help you write bug free
code.  For example statement blocks can be annotated with conditions
that are supposed to be true on entry and exit.  This is supposed to
enforce a "programming by contract" mentality.

Perl-style tainting would be an interesting thing to add to another
language.  IMHO, Perl is not a good safe language because its syntax is
even more obscure than C's.  (It does have the advantage of being almost
completely type safe though.)  Tainting is a good security measure,
though, which would be good in a language like Eiffel.

-- 
Pete

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

It's Time to Abandon Insecure Languages

[R. A. Hettinga]

http://www.eweek.com/print_article/0,3668,a=28859,00.asp


eWEEK

July 8, 2002
It's Time to Abandon Insecure Languages


The security of the internet took a one-two combo to the gut last month
when we learned of remotely exploitable security holes in Apache HTTP
Server and OpenSSH. The costs of these two problems could be enormous-the
foundation of the worst Internet worm yet-and should prod us all to rethink
the way security-sensitive software is written.

Apache currently runs 56 percent of the sites on the Internet-more than 21
million domain names-and OpenSSH is the padlock used to protect the most
security-sensitive servers in an organization. Patches for both were
quickly made available, but those patches must still be applied, and until
they are, sites will remain vulnerable.

However, we need to look at the deeper implication-that even in the most
successful security-conscious projects, serious flaws can remain buried for
years and then claw their way up through the dirt for our blood.

Both these problems are due to our old nemesis, the "buffer overflow" that
lets rogue code sneak in through a door marked "data." These holes
demonstrate that we must switch to writing security-sensitive code in
managed environments, like the Java virtual machine or .Net run-time, that
continually enforce code/data distinctions.

We have to get over the bias that there's something dishonorable about
choosing languages that prize safety over pure efficiency. Hardware
capacity is growing faster than programmer accuracy. It's time to require
case-by-case justification of C and C++, the tools that grease the floor
and let developers run with knives.

What we don't need are cocksure code cowboys who stick with insecure
languages because they think they can do better than the Apache or OpenSSH
development teams. The correct lesson is that even exceptionally skilled
security fanatics, poring over source code line by line, year after year,
still make mistakes.

Developers need some steel in their spine to commit to safety before other
goals; ISVs need to stop taking chances their bugs won't be found; CPU and
language creators need to continue research into just-in-time compiler
performance; and customers need to speak with their wallets. It's time for
new thinking about how critical software is created.





Copyright (c) 2002 Ziff Davis Media Inc. All Rights Reserved.

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]