Posted on

Infosec 2013 – First Impressions

I’m here at Infosec 2013 at Earls Court, looking for the latest trends in Information Security. It feels a bit more sober this year, but this could be to do with the number of people turning up on the Tuesday. Hot topics? Well user privilege management seems to be headlining, at least a bit. That’s what the marketing people are aiming their guns at anyway, but it’s too early to tell what the real story will be.

I had a look at the “new” Firebox firewalls. Their big thing is application management, which is, apparently, a big selling point. Rather than just blocking out particular web sites based on URL, they are using signatures on web pages to do the blocking. This approach allows companies, for example, to allow people to access profiles on Facebook but not play games. It’s a good idea, but I don’t see how it can get around the YouTube problem – a mixture of business and entertainment videos (often embedded in supplier and customer web sites) with no obvious way to tell between them. I’ll be taking a closer look.

New at the show is South Korean cyber security company AhnLab. Given my recent comments on the North Korean cyber-warfare claims, they’ll be interesting to talk to.

What’s going on in the cyber-security business-wise? Overseas outsourcing is a recurring theme. Scary!

 

Posted on

Lighttpd in a FreeBSD Jail (and short review)

Lighttpd is an irritatingly-named http daemon that claims to be light, compared to Apache. Okay, the authors probably have a point although this puppy seems to like dragging perl in to everything and there’s nothing minuscule about that.

I thought it might be worth a look, as Apache is a bit creaky. It’s configuration is certainly a lot simpler than httpd.conf,although strangely, you tend to end up editing the same number of lines. But is it lighter? Basically, yes. If you want the figures it’s currently running (on AMD64) a size of 16M compared to Apache httpd instances of 196M.

But we’re not comparing like for like here, as Lighttpd doesn’t have PHP; only CGI. If you’re worried about that being slow, there’s FastCGI, which basically keeps instances of the CGI program running and Lightttpd hands tasks off to an instance when they crop up. Apache can do this (there’s the inevitable mod), but most people seem happy using the built-in PHP these days so I don’t think FastCGI is very popular. It’s a pity, as I’ve always felt CGI is under-rated and I’m very comfortable passing off to programs written in ‘C’ without there being an noticeable performance issues. Using CGI to run a perl script and all that entails is horrendous, of course. But FastCGI should level the playing field and allow instances of perl or any other script language of your dreams to remain on standby in much the same way PHP currently remains on standby in Apache. That doesn’t make perl or PHP good, but it levels their use with PHP on Apache, giving you the choice. And you can also choose  high-performance ‘C’.

This is all encouraging, but  I haven’t scrapped Apache just yet. One simple problem, with no obvious solution, is the lack of support for the .htaccess file much loved by the web developers and their content management systems. Another worry for me is security. Apache might be big and confusing, but it’s been out there a long time and has a good track record (lately). If it has holes, there are a lot of people looking for them.

Lighttpd doesn’t have a security pedigree. I’m not saying it’s got problems; it’s just that it hasn’t been thrashed in the same way as Apache and I get the feeling that the development team is much smaller. Sometimes this helps, as it’s cleaner code, but it’s statistically less likely to have members adept at spotting security flaws too. I’m a bit concerned about the FastCGI servers all running on the same level, for example.

Fortunately you can mitigate a lot of security worries by running in a jail on FreeBSD (it will also chroot on Linux, giving some degree of protection). It was fairly straightforward to compile from the ports collection, but it does have quite a few dependencies. Loads of dependencies, in fact. I saw it drag m4 in for some reason! Also the installation script didn’t work for me but it’s easy enough to tweak manually (find the directory with the script and run make in it to get most of the job done). The other thing you have to remember is that it will store local configurations in /usr/local on BSD, instead of the base system directories.

To get it running you’ll need to edit  /usr/local/etc/lighttpd/lighttpd.conf, and if you’re running in a jail be sure to configure the IP addresses to bind to correctly. Don’t be fooled: There’s a line at the bottom that sets the IP address and port but you must find the entry server.bind in the middle of the file and set that to the address you’ve configured for the jail to have passed through. This double-entry a real pooh trap, especially as it tries to bind to the loopback interface and barfs with a mysterious message. Other than that, it just works – and when it’s in the jail it will happily co-exist with Apache.

I’ve got it running experimentally on a production server now, and I’ve also cross-compiled to ARM and it runs on Raspberry Pi (still on FreeBSD), but it was more fun doing that with Apache.

When I get time I’ll do a full comparison with Hiawatha.

Posted on

Why won’t my IAR compiler work past 2000? – UBROF bug

If you check out IAR’s web site you’d be forgiven for thinking that IAR compilers had no problems with dates past 2000. You’d be quite wrong – they’ve got more Y2K bugs than a termite hill and they’re too shy to tell you about them.

It’s true that most tools since late 1998 are fixed but pretty much all the older ones have the same set of funnies. Most listings will be dated 22/Jun/102; the ‘C’ __DATE__ macro has a similar amusing effect, and so does the DATE 6 equivalent in the assembler. Embarrassing but not fatal, although it would have been nice if they’d owned up to the world on their web site.

However, if you’re using the IAR debug object format, UBROF, you may be in for a much worse surprise. The UBROF format has a header containing the link time and date. This is also messed up, such that several debuggers are known to reject files linked post-2000 due to invalid header information. This isn’t a bug in the debugger

IAR’s solution is to upgrade. Well they would say that, wouldn’t they? You don’t fancy jumping your compiler version on three years? Rather stick with the devil you know? Then download iarfix.com now. Simply run this on your output file after the linker has done its stuff and it’ll fix up the header and anything else it can find that might be wrong with it. You can even give it a wildcard file spec if you have a directory full of stuff that chokes your debugger.

It’s not supported, not guaranteed and not properly tested but you’re welcome to try it. If it doesn’t do it for you then let me know and I’ll think about updating it – but there have been no complaints in the last twelve months. If you’re the type that really must have a support contract for ISO9000 reasons then I’ll sell you one for £1000 a year and make damn sure it works for you. Still interested? I thought not. Enjoy!

As a final kick in the teeth, IAR managed to release a few disastrous ‘compliance’ updates, some of which have made it into the wild. They fix the embarrassing listing problems but, for some inexplicable reason, stop and catch fire when asked to read or write to a file with a year stamp of 2000 (including ones that it has just opened itself). Was a complete mystery why how or why they could have coded their file handling code in such a way that the date mattered, and even more of a mystery why they didn’t notice it when they tested it. Nice once guys! If you wait until 2001 then these rogue tools start working again without any apparent problems.

I’ve now disassembled one of their iffy compilers if anyone’s interested What on earth did IAR do to break their compiler?

Finally, if anyone from IAR in Sweden is reading this and thinks I’m being a bit hard on them – think about this: If you disclosed this information on your web site instead of pretending that everything was okay then none of this would have been necessary. Your customers are going to find out soon enough anyway, and when they do you’re going to look even worse.

(Originally published as www.fjl.co.uk/answers/faq/q3.htm)

Posted on

What on earth did IAR do to break their compiler?

Some IAR compilers have an horrendous year-2000 bug. It took me about 30 minutes to disassemble one of their compilers and track down what they’d done wrong.

Basically, for some reason I don’t have the inclination to figure out, all file-open and file-close operations go through one of their own weird routines that wraps around the POSIX open() and creat() functions, which are themselves wrappers for the Windows equivalent. As part of this pantomime the date stamp is obtained. What they’re actually doing is loading the date stamp year portion (which is the year offset from 1900) with 100 before making the call and checking to see it isn’t still 100 when it returns. If it is, they assume that the open/creat process has failed somewhere because no new year was loaded. The only snag, of course, is that 2000 is actually 100 years from 1900 – someone obviously assumed it’d wrap to 00.

You can easily patch this problem out by changing the rogue value to 0xff or similar if you feel so inclined. To find it just start with the OpenFile() dynamic link in the executable (we’re talking Win32 exe here), look to see what calls it. This looks like a standard library the open() function. Then look to see what calls that (the weird IAR function). Inside look for where 100dec is loaded into a structure and replace it with something else. Don’t be tempted to play a little trick on your colleagues and time-bomb it for another year in the future.

I’d be most interested if someone with access to the source code could confirm or reject this explanation – in confidence of course!

(Originally published as www.fjl.co.uk/answers/faq/q3a.htm)