I work for a fortune 100 company in the telecom space. They are
absolutely dirtying their shorts over security concerns. They haven’t
had any major fallout yet, but they figure it’s inevitable. They have
been flying in experts to tell us all how to write safer C code.
Having witnessed several such 1 to 3 day tirades on how to write safer C
code, I think I can summate 99% of the issue as:
“make sure you don’t over-run any buffers”. This is because almost all
of the “exploits” that don’t involve walking in through an open door
involve pushing executable code into an over-written buffer.
I’ve been thinking it over, and I can’t for the life of me think of a
way to over-run a buffer in Ruby.
Is this the same as thinking one is safe from viruses because he’s
driving a Macintosh, or is Ruby (and any other ducktyped and garbage
collected, etc. etc. language) automatically much safer by default?
Asking the same question in a different way, does Ruby have any similar
“Achilles heel” that one has to be careful of to avoid providing the
hackers out there with “exploits 'aplenty”?
thanks,
jp
On May 31, 2006, at 9:34 PM, Jeff P. wrote:
I work for a fortune 100 company in the telecom space. They are
absolutely dirtying their shorts over security concerns.
Having witnessed several such 1 to 3 day tirades on how to write
safer C
code, I think I can summate 99% of the issue as:
“make sure you don’t over-run any buffers”.
I’ve been thinking it over, and I can’t for the life of me think of a
way to over-run a buffer in Ruby.
The equivalent in ruby is “Never trust tainted data”.
Setting $SAFE appropriately for your application will cause
exceptions to be thrown when you try to work with tainted data. By
default this protection is off.
See:
http://www.rubycentral.com/book/taint.html
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
On 6/1/06, Jeff P. [email protected] wrote:
Is this the same as thinking one is safe from viruses because he’s
driving a Macintosh, or is Ruby (and any other ducktyped and garbage
collected, etc. etc. language) automatically much safer by default?
Yes and no. The main thing with scripting languages like Ruby is that
insecure programming practices lead to different, and higher-level
classes of bugs than your garden-variety buffer overflow. You probably
won’t be able to write a Ruby program that is vulnerable to buffer
overflows unless there is such a bug in Ruby itself (highly unlikely)
or within an extension library you’re using (most of them tend to
themselves be written in C). However, there are other classes of
security bugs that affect these kinds of languages. Take for example
SQL injection attacks. These happen because a program foolishly
constructs an SQL query using raw data input from an untrusted
source. For example, if we had some Ruby-DBI code that did the
following:
sql = “SELECT * FROM usertable WHERE user=‘#{username}’”;
result = @dbh.select_one(sql)
where username is obtained from, say, a web form, what happens if
username happens to be something like “'; DELETE FROM usertable; '”?
The moral of the story is to never use any data coming in from
untrusted sources without validating it first, and Ruby has (like
Perl) a notion of tainted data that allows one to defend against this
problem. If your $SAFE mode is set high enough, in the above example,
username would be considered tainted, and the construction of the SQL
statement would have caused a tainted data exception, alerting you to
the problem before it becomes an issue. I would have to validate
username first by passing it through a regex before I could use it in
that way.
Jeff P. wrote:
Asking the same question in a different way, does Ruby have any similar
“Achilles heel” that one has to be careful of to avoid providing the
hackers out there with “exploits 'aplenty”?
Watch your 'eval’s. If incorrectly used, they’re a MUCH easier way for
an attacker to execute code 
If you work hard enough at it, you can open anything. If you’re sneaky
enough, you can avoid getting caught pulling off “small” crimes. And if
you plan well enough, you can pull off something spectacular – once.
But the odds are – even in C – that you can’t do it all --break into
a major application, steal or corrupt data, and not get caught.
That said, do what satisfies your attorneys, insurance providers and
executives, not what’s technically correct. That’s the Fortune 100 way.
Jeff P. wrote:
thanks,
jp
–
M. Edward (Ed) Borasky
Jeff P. wrote:
I’ve been thinking it over, and I can’t for the life of me think of a
way to over-run a buffer in Ruby.
Is this the same as thinking one is safe from viruses because he’s
driving a Macintosh, or is Ruby (and any other ducktyped and garbage
collected, etc. etc. language) automatically much safer by default?
I know of specific examples of some interpreted languages experiencing
the same type of buffer overruns. Generally they involved thin wrappers
around unsafe C-level functions, generally the string formatting
functions. I don’t know if Ruby specifically suffers from any, but the
same potential exists in most interpreted languages that I know of.
You can guard against it in your code the same way you would in C. Check
any arguments that come from outside your program control and that are
passed into any unsafe C-level functions (those involving varargs, etc,
eg. printf-family of functions). Same for exec/forking, etc.
Randy.