Vint Cerf

[Lohmatiy]

Languags like Perl, Python, Ruby, and Java don't give naked access to pointers to memory... thus it is effectively impossible to get the kind of buffer overrun exploits that are so common in poorly written C programs.

http://www.google.com/search?q=%28ruby%7Cpython%7Cperl%29+%22buffer+overflow%7Coverrun%22&btnG=Search
http://www.google.com/search?q=%28ruby%7Cpython%7Cperl%29+%22buffer+overflow%7Coverrun%22&btnG=Search

[quadz]

http://www.google.com/search?q=%28ruby%7Cpython%7Cperl%29+%22buffer+overflow%22&btnG=Search
http://www.google.com/search?q=%28ruby%7Cpython%7Cperl%29+%22buffer+overflow%22&btnG=Search

Yes... but if that happens it's a bug in the language, not in the program. 

Which localizes the problem to one codebase.

Compare that to: http://www.google.com/search?hl=en&q=sendmail+%22buffer+overflow%22&btnG=Google+Search
http://www.google.com/search?hl=en&q=sendmail+%22buffer+overflow%22&btnG=Google+Search




I.e. sendmail is just one C program, with numerous different buffer overflow exploits discovered throughout its history.  If it were written in, say, Java, then the only time it could have a true buffer overflow exploit is when a bug is discovered in the JVM. . . . Which does happen sometimes, but I think pretty infrequently compared to sendmail.

[Lohmatiy]

Which localizes the problem to one codebase.

Still hard to say which case is worse. For example, lets imagine that someone has a 0-day Perl buffer overflow exploit. He can 'hack' nearly ALL programs that use the vulnerable language feature. And if he doesn't make the exploit public, not one's able to do anything about it. Meantime, a correctly written C program isn't vulnerable to these attacks, despite the language version.

[quadz]

Still hard to say which case is worse. For example, lets imagine that someone has a 0-day Perl buffer overflow exploit. He can 'hack' nearly ALL programs that use the vulnerable language feature. And if he doesn't make the exploit public, not one's able to do anything about it. Meantime, a correctly written C program isn't vulnerable to these attacks, despite the language version.

But most correctly written C programs still use the standard library.  So buffer overflows in glibc (for example) put you back in the same category as buffer overflows in Perl.

No?

[Lohmatiy]

Well, that's true... You overflowed my buffer in this discussion ))
Anyways, from a hacker's point of view, the frequency of discovering buffer overflow exploits doesn't matter at all, if something could be vulnerable, it IS vulnerable and it can be used, and everything that a human makes, is vulnerable by its nature.
 

[kren.Z]

Good point, lohamity. You speak of flawed design, It's interesting to think philosophically about the design that nature herself produces. Is her architectural mapping simply the byproduct of random sequencing iterating since the beginning of time?... The mind boggles at it's beauty.

[quadz]

from a hacker's point of view, the frequency of discovering buffer overflow exploits doesn't matter at all, if something could be vulnerable, it IS vulnerable and it can be used, and everything that a human makes, is vulnerable by its nature.

I agree, there will always be some exploits discovered, but at the same time I think putting layers of security around a program is still useful.

But yes... over the years I've discovered malware on my windows box two times.  The first time was a result of me being really stupid about installing some screensaver software off the web.  (It was bundled with a bunch of spyware.)  The second time, was a trojan that got on my system via a browser java applet JVM exploit.

I was running a very old version of Java and never bothered to update. (Like 1.1 or something.) Didn't really think about it until I discovered the infection.  Now I pay more attention to keeping up-to-date... but as you point out, that doesn't help with a "0-day" exploit.

STILL... Even though I've been bitten by a JVM exploit, I don't think it's a worthless concept.  I'm still going to trust running a random browser applet on my system, far more than I would trust running a random .exe.

And I guess that is my point... I think by default, untrusted software should have to run in a secure sandbox, like java applets do.  It's true there will still be occasional exploits that allow the program to escape the sandbox, but I think that would be a tiny fraction of the exploits we see today, where naive web users are tricked into downloading and running .exe's. 


Regards,

quadz

[QwazyWabbit]

No system made by man is perfect. There will always be a flaw that can be exploited. -end philosophic platitude-

Seriously, programming languages are evolving and getting better at being good tools and not providing implicit attack points.

C was conceived before there was a substantial Internet. A program could trust its own data. The only danger to a UNIX box was it's users. UNIX as it was implemented had all kinds of flaws that if you placed a naked unix box on the net today, it would perish as fast as any Windows box. There is nothing wrong with the C language itself, it has all the constructs needed in most programs. There were some compromises made back when the ANSI standard was being set and the "standard library" was being defined that led to some pretty stupid decisions and implementations in the library that made it hard to not make mistakes or that automatically created some opportunities for exploitation. Those decisions were made by the commitee seeking compatibility and breaking the least amount of existing code, they weren't very security concious at that time. At the same time nothing prevents a programmer from designing his own library focused on security and ease of use and correctness. Perl, PHP and Python were written in C, IIRC, and fundamentally use the standard C library at their core.

As for sendmail, it's almost as ancient as UNIX itself. It's old and complex and if it still has vulnerabilities it's probably because it's hard to maintain. I have never looked at it's code but I would imagine it has some places that could stand some good security review.

Language selection is based on requirements or personal preference. I can almost write a C program faster than I can in Perl. That's because I know C a little better. My Perl programs tend to be a little C'ish and I will sometimes make some idomatic mistakes.

Java is a good tool but the programs tend to be slow for the same functionality in a compiled language like Perl or C. The trouble I have with JVM, MFC, and the managed code libraries like the .NET framework is that you are dependent on a library you know almost nothing about, can't fix, can't maintain, can't snoop, and can't do without. You become a library junky. Dependent on a junky library. How many JVM versions are there? What did they fix and why? (See buffer overflows.) Sun has made JVM deployment mistakes all over the place and it's a PITA.

A good programmer writes his own libraries or at least organizes his functions in such a way that he can re-use them to build better programs. If you don't like malloc()/free() you can write your own. Good luck. Java takes that right away from you. They don't call it garbage collection for nothing. I remember coding in BASIC on the TRS-80 I in 1977 and watching my program stall suddenly while the BASIC interpreter collected garbage. We have not gone that far, really.

Anyone read the coding standards manual for the JSF recently? FYI, flight systems code is in C++.

[quadz]

There is nothing wrong with the C language itself, it has all the constructs needed in most programs. There were some compromises made back when the ANSI standard was being set and the "standard library" was being defined that led to some pretty stupid decisions and implementations in the library that made it hard to not make mistakes or that automatically created some opportunities for exploitation. Those decisions were made by the commitee seeking compatibility and breaking the least amount of existing code, they weren't very security concious at that time.

Yes, I've often wondered how things would have turned if the standard library, from the very beginning, had only consisted of functions like snprintf() instead of sprintf(), etc. 

Language selection is based on requirements or personal preference. I can almost write a C program faster than I can in Perl. That's because I know C a little better. My Perl programs tend to be a little C'ish and I will sometimes make some idomatic mistakes.

For me it indeed depends on the particular problem to be solved.  If I'm going to write a little OpenGL demo I'm likely to use C or C++, partly for performance reasons, and partly because using the OpenGL API via Ruby doesn't give me much gain over using the same API in C.

But for a fairly broad category of problems, I'd never willingly choose C anymore... I find it hard to escape the low-level tedium of memory management details in C.  In a scripting language I can just throw data around with relative ease.  And in many cases I don't care about performance - so there's no downside.

For example, I hacked up the following this afternoon in about 20 minutes, including time spent from an interactive ruby prompt, opening a socket and manually sending requests to the server to explore the quirks of shoutcast's poor conformance to the HTTP standard...

Now it's not like a C version of this would be hugely more complex... but from my point of view it would have been considerably more tedious.

This is a CGI script to query our shoutcast server for its online/offline status and return a corresponding .GIF image reflecting that status. 

( Running at: http://tastyspleen.net/quake/shoutcast/status.cgi )


#!/opt/bin/ruby

require 'socket'

$SAFE = 1

host = "localhost"
port = 8000

online_image = "tastycastsmall_on.gif"
offline_image = "tastycastsmall_off.gif"


# The shoutcast HTTP server seems VERY picky about the request used to access it.

resp = ""
TCPSocket.open(host, port) do |sock|
  sock.print "GET /7.html HTTP/1.0\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)\r\n\r\n"
  while dat = sock.gets
    resp << dat
  end
end


# the HTML returned is something like:
# <HTML><meta http-equiv="Pragma" content="no-cache"></head><body>0,0,8,32,0,128,Explosions In The Sky - once more to the afterlife</body></html>

online = false
if resp =~ %r{<body>(.*?)</body}i
  fields = $1.split(",")
  online = fields[1] == "1"
end

img_fname = online ? online_image : offline_image
img_data = File.read(img_fname)
img_data.untaint

print "Content-type: image/gif\r\n\r\n"
print img_data


Again, nothing in the above script is really a big deal... But it was a breeze to write, because at no point did i have to concern myself with low-level details...

Java is a good tool but the programs tend to be slow for the same functionality in a compiled language like Perl or C.

I'm no java fanboy.... But Java has been closing the performance gap with C, and for the past decade or so it has been better than 2x slower than C on average on a number of benchmarks^[1]... Occasionally faster than C in some benchmarks, when the JIT compiler kicks in.  (Not that benchmarks ever tell the whole story, ... but anyway... )

The trouble I have with JVM, MFC, and the managed code libraries like the .NET framework is that you are dependent on a library you know almost nothing about, can't fix, can't maintain, can't snoop, and can't do without. You become a library junky. Dependent on a junky library. How many JVM versions are there? What did they fix and why? (See buffer overflows.) Sun has made JVM deployment mistakes all over the place and it's a PITA.

A good programmer writes his own libraries or at least organizes his functions in such a way that he can re-use them to build better programs.

Indeed, I remember with some fondness writing games that would take over the whole machine, and where it was just my code and the BIOS.

That's really not feasible anymore for most modern desktop applications--and I don't mean the part about taking over the machine, but rather an increasing dependence on third party libraries.  How often does one have time to write ones own JPEG library, TIFF library, MPEG library, direct screen blitting routines, windowing library, sound library, TCP/IP stack, etc. etc. etc.  It's just not practical to reinvent or recode all the components needed in a modern application...

That said, I don't like MFC either.

If you don't like malloc()/free() you can write your own. Good luck. Java takes that right away from you.
They don't call it garbage collection for nothing. I remember coding in BASIC on the TRS-80 I in 1977 and watching my program stall suddenly while the BASIC interpreter collected garbage. We have not gone that far, really.

Garbage collection algorithms have come a long way recently.  After Java switched to a generational garbage collector, its allocation speeds surpassed the best malloc() algorithms, measured in average machine instructions per call:

http://www.ibm.com/developerworks/java/library/j-jtp09275.html

I'm not even really much of a fan of Java... but I've got to give props to the JVM implementors... It ain't the slowpoke it used to be.  And garbage collection no longer needs to incur huge pauses while it marks and sweeps the whole heap the way it used to.


Regards,

quadz

[QwazyWabbit]

I liked perl, it's very much like a high-level C and it's great for smallish programs that one person can manage. Unfortunately I kind of burned out on it doing web backends for a friend who promised to pay for some urgently needed stuff and learning Perl against a deadline or under delivery pressure is not fun. Left a bad taste when the pro quo fizzled. I deal with it. I do small stuff for myself from time to time. Another feature of perl's pedigree is the cult of anti-cultists who surround it in the newsgroups. Submit code to the comp.lang.perl group at your own peril. They will call it cargo cult, lame, rip it to shreds even when it came from something previously posted as good stuff. Perl at the time I was learning it was still evolving, if it was written yesterday it's obsolete cargo-cult today. Yesterday's detainting is today's vulnerable code.

Ruby sounds like fun. I will have to find some time to look at it more closely.

Java is becoming the code du jour. It's in my Blackberry and seems to do the job nicely. I need to browse for some open source stuff for the BB, maybe a nice RPN calculator like my HP48. hmmmmm color graphics.... 

[reaper]

java programs suck and they're slow, so it's fair to say java sucks I guess, although maybe it's not necessarily java's fault. maybe if more stuff ran on the servers it would be good, I don't know, but practically every java program I use sucks.

i'm not a good programmer, that's for sure, but don't you pretty much have to use C, or assembly to program certain devices, like routers.   TCAM memory on a router is ultrafast, an embedded on the linecards, you check traffic against filters in the TCAM.  I believe this memory contains an array of pointers to link lists, which makes the speed very efficient.  i'm not a programmer, although I know what link lists and pointers are, but I may have bastardized the whole concept.  when you allow someone to manage memory like this, isn't it hard to take away the potential for misuse of data?

like to be this efficient, you can't check the bounds of an array when copying data, yet it still should be done?


and the botnets really bother me, I don't know how someone can fix them, and I don't think anyone does, am I wrong about that, is there some type of solution?  the internet backbones have been crushed with worms like the slammer before, and the botnets can do roughly the same thing, and if not, they could. so even these companies like akamia, with their nifty solutions for load-balancing via anycast and what not, are still in trouble..  theres nothing they can do

I believe we should get the best team together, and hunt these people, they can use clever little tricks to take over computers, we can use clever little tricks to find them slipping up, and then theres people with guns, and they might not have any answers for that!


 

[kren.Z]

One things for sure, we need to build a team and start coding. 

[reaper]

One things for sure, we need to build a team and start coding. 

sure, lets code a kick ass tastyspleen  cobol fianacial accounting program.  with some leet text menus

[quadz]

java programs suck and they're slow, so it's fair to say java sucks I guess, although maybe it's not necessarily java's fault.

Yes... I want to be clear that when I'm talking about speed, I'm talking about how fast code executes on the JVM.  Java programs themselves seem to often be written on top of layers and layers of application support libraries, and can end up seeming bloated and slow.  But the slowness isn't the fault of the underlying compiler and virtual machine anymore...


Regards,

[quadz]

lets code a kick ass tastyspleen  cobol fianacial accounting program.  with some leet text menus

Haha... I've never programmed in COBOL but I still get some wry amusement from the verbosity of the "Hello World" example in that language:

Code: [Select]

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID.     HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400     DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800     EXIT.
Still, must have looked pretty high-level in 1959...