Re: It's Time to Abandon Insecure Languages

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)

Re: It's Time to Abandon Insecure Languages

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 iss

Re: It's Time to Abandon Insecure Languages

[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.

Re: It's Time to Abandon Insecure Languages

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 individ

Re: It's Time to Abandon Insecure Languages

[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

Re: It's Time to Abandon Insecure Languages

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

Re: It's Time to Abandon Insecure Languages

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 mi

Re: It's Time to Abandon Insecure Languages

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

Re: It's Time to Abandon Insecure Languages

> 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 > man

It's Time to Abandon Insecure Languages

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 cos