Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

August 31, 2007

Suboptimized

The Instiki installation on golem has performed quite solidly. It’s not the fastest Web application you’ll ever see, but it’s been pretty darned stable. Since I was giving some talks this summer, I installed a copy on my laptop, so that I could serve (and, for that matter, prepare) the slides locally.

That proved to be nothing but a headache. The damned thing would segfault at the drop of a hat. Eventually, I gave up, and relied on the wonders of the internet to deliver my slides from my office in Austin to wherever I happened to be.

A little bit of googling around revealed that these Segmentation Fault errors are not an uncommon problem. And it’s not Instiki; the problem lies with Ruby itself. In fact, it appears to be a problem, not just with the Fink-installed version of Ruby that I was using, but with any late-model Ruby, compiled with GCC 4.0.

Now that I’m back in Austin, I set about to try to fix the matter.

The key insight came from this blog post, which pointed to a problem with GCC 4’s optimizations. My solution, which was a little less drastic than his, was to change

SetCFLAGS: -g -Os

to

SetCFLAGS: -g -O

in /sw/fink/dists/unstable/main/finkinfo/languages/ruby18.info and then do a

fink rebuild ruby ruby18-dev sqlite3-rb18

(and reinstall the itex2MML Ruby bindings). Instiki’s been a bit slower (but rock-solid stable) since then.

Mind you, you should only do this if Ruby has trouble on your platform, too. As I said, it works just fine with the default compiler optimizations on golem (a G5 PowerMac).

Posted by distler at August 31, 2007 11:33 PM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/1414



8 Comments & 1 Trackback

Re: Suboptimized

-Os optimizes for size instead of speed. For example, it does not inline functions. Perhaps with the exception of embedded systems nobody would want that.

The best optimization in gcc is -O3 (which is the same as any number >3).

By the way, how secure is the setup? Isn’t this similar to running a web server with cgi? How long did it take for the apache people to get their default setup really secure? ;-) Did you try the java-based ruby interpreter?

Posted by: Volker on September 1, 2007 9:44 AM | Permalink | Reply to this

Re: Suboptimized

-Os optimizes for size instead of speed. For example, it does not inline functions. Perhaps with the exception of embedded systems nobody would want that.

The best optimization in gcc is -O3 (which is the same as any number >3).

-Os is, as I understand it, -O2 without a few of the optimizations that would increase the size. So, whatever is causing Ruby to segfault under -Os would also cause problems under -O2 and -O3.

The next step down is -O, which seems to work.

By the way, how secure is the setup? Isn’t this similar to running a web server with cgi?

On my laptop, Port 2500 is firewalled, so it’s completely secure.

On a public server, yeah, there are security issues to think about, as there are with any Web Application. The most obvious one, here, is Cross Site Scripting, which, indeed, I’ve spent quite some time thinking about.

Posted by: Jacques Distler on September 1, 2007 10:45 AM | Permalink | PGP Sig | Reply to this

Re: Suboptimized

-Os leaves out padding to align things for best memory access, that can also break code if you do it wrong. But my point was that -Os should not have been there to start with, either optimize for speed or not at all. Actually I’m not surprised that gcc 4.0 has some nasty bugs (point-zero release). 4.1.2 works well and 4.2.1 is out since about a month.

As for the security, I’m more worried about the impact on the server instead of the user. Having an interpreted language helps somewhat but also introduces new dangers (like the infamous \0 within perl strings). And you really don’t want your interpreter to segfault, ouch. I’m only trusting apache because a) it has been out for many years and b) its locked down with selinux. Just wondering if you have something reassuring to say in that regard :-)

Posted by: Volker Braun on September 1, 2007 1:33 PM | Permalink | Reply to this

Re: Suboptimized

Then again, code written in Perl cannot possibly have a buffer overflow vulnerability as long as perl itself does not have any (which has been true for a decade or so). You cannot say the same of code written in C, like, say, Apache…

The \0 problem is more of a leaky abstraction issue, very similar in nature to SQL injection and XSS – issues of which no language currently in use will protect you. (Whereas a language with a mathematically sound type system such as Haskell might.)

Posted by: Aristotle Pagaltzis on September 1, 2007 3:16 PM | Permalink | Reply to this

Re: Suboptimized

SQL Injection attacks?

Hmmmm…. Gotta think about that.

Is there a test suite somewhere, comparable to this one for XSS attacks?

Posted by: Jacques Distler on September 1, 2007 7:53 PM | Permalink | PGP Sig | Reply to this

Re: Suboptimized

Not really. It’s much harder to test SQL injection because success isn’t directly apparent from the output you get.

External injection testing generally tries to provoke an error message on unusual input – a tedious job that is usually automated with one-off scripts for the app under scrutiny, if at all.

But if you have the source, and there’s no abstraction layer over the SQL in use, then it’s usually pretty easy to find SQL injection attacks simply by running the right regexen over the source. Eg. to scan Perl code, I’d use something like this:

^\s*(?i:select|insert|update|delete).*=\s*'?[\$\@]

This will ferret out things like DELETE FROM table WHERE name='$name'.

Of course, this can only prove the presence of SQL injection holes, not their absence.

If there is an abstraction layer over the database in use (usually an ORM; I assume Instiki uses ActiveRecord?), then you have a much bigger job, because you’ll have to audit the entire thing manually. However, ORMs are usually written much more carefully than one-off queries, and much like with buffer overflows when writing in Perl vs C, once the abstraction layer is audited and found to be safe, applications using it are almost certainly safe in that regard as well.

Posted by: Aristotle Pagaltzis on September 2, 2007 3:26 AM | Permalink | Reply to this

SQL Injection

Yes, Instiki uses ActiveRecord. But you also find examples where it subclasses ActiveRecord classes and constructs its own SQL queries. The trick is finding places where one fails to call sanitize_sql() on the resulting query.

As with my recent discovery about “categories”, it would be best to fling arbitrary bad data at the application and see what produces errors. I just worry that I’m being insufficiently clever about crafting the bad data.

Posted by: Jacques Distler on September 2, 2007 11:06 AM | Permalink | PGP Sig | Reply to this

Re: Suboptimized

Let’s compare apples to apples, shall we? Apache is a webserver. Instiki is a CGI application. It can run under a variety of webservers: WEBrick (the default, which comes bundled with Ruby), lighthttpd or Apache (using either Mongrel or FastCGI).

By all means, use the webserver which provides you with the best balance of security, performance and convenience.

As to security issues in the application, that, too can be divided between issues in the framework (Rails) and those peculiar to the application itself.

As I pointed out, properly sanitizing user input is one big issue that needed to be addressed. Instiki now has the best sanitizer available on any platform (far better than the sanitizer MovableType uses).

There were some more minor ones (to do with sloppy file permissions) that I have also addressed in my version of Instiki.

Of course, there are no guarantees. Despite all my tinkering, I certainly haven’t gone through every line of code in Instiki (let alone in Rails).

Still, as Aristotle points out, there are whole classes of security issues, that could easily beset an application written in C, that are not a problem in Ruby (or Perl or Python).

Posted by: Jacques Distler on September 1, 2007 5:56 PM | Permalink | PGP Sig | Reply to this
Read the post XSS 2
Weblog: Musings
Excerpt: Security is a journey, not a destination.
Tracked: September 2, 2007 1:57 AM

Post a New Comment