How to submit suspected malware samples?

A quick tip: if you have file(s) which you suspect that are malicious, submit them to any of the following places:

• VirusTotal
• VirScan
• Jotti's malware scan
• Virus.Org Rogue File Scanning Service
• Virus Chief
• FilterBit
• NoVirusThanks

Beside the fact that these sites will eliminate or enforce your suspicion (based on the number and types of detection they return), they will all send files which are detected at least by one product to the ones which don't detect it. This is a much faster way to submit samples to a large set of AV vendors at once.

Update: added some more links

Update: added link to NoVirusThanks

Game Over - You Lost!

The famous security researcher Joanna Rutkowska has posted on her blog an article entitled The Game Is Over! and as a typical second class blogger I jump on it and give my (unrequested) comments :-).

The post reiterates two of the ideas she has been promoting recently:

• The security industry doesn't focus enough on the detection of kernel-level compromises
• Current OS's and programs are not designed such a way that their integrity can be easily verified

My opinion about this matter is: generic detection of kernel level compromise is very, very hard (I would venture to say impossible). The good news is that 99.9999% of all kernel level malicius code out there can be detected by a sufficiently skilled individual (the fact that the hourly rates of somebody with these skills is most probably very high is an other question). Many of them however can not be detected by point-and-click tools. The (economical) equation is the following: if you got compromised and you are a large company who can afford to bring in outside specialist (because most probably you don't have them on staff), you can pretty much track down all the traces of the infection with a very high probability. If you on the other hand are a home user - it is truly game over for you and all you can do is to start from the beginning the wipe / reinstall / patch cycle.

Now for the fact that all of the generic defenses incorporated in the OS (like ASLR, stack canaries, etc) can by bypassed: this is true. However, life is a game of probabilities (or ROI if you are an economist :-)). If you have a new vulnerability, which can be exploited with a probability of 0.9 on systems which don't have any of the security measures, with a probability of 0.5 on systems which have some of these features and a probability of 0.1 on systems which have all the security features, would you classify these solutions as useless just because they failed to totally prevent the exploitation? The provided you nine times better security than a vanilla system with none of these feature activated! I can certainly see the desire of Joanna Rutkowska for finding the best solution, given her mathematical background - where most statements can be either proven right or wrong - but IT isn't mathematics :-).

Finally: building a verifiable OS is an interesting idea, but it's just a research topic and most probably it will remain so for the longest time (just look where Hurd or Minix is and where Linux is - the first two are focusing on getting things right while Linux is focusing on getting things done).

An other tool to manage security in Windows

One of the first posts on this blog was about different (free) options you have to temporarily elevate your privileges under Windows. So it is natural that this blog post from George Ou sparked my interest. It talks about a product, BeyondTrust, using which you can temporarily elevate the privileges of certain applications and provides a centralized management interface to it through Active Directory.

Their website contains the usual propaganda, like protection against zero day threats, but this is not why I'm mentioning them. I'm talking about them because I suspect that I found a loophole in their bulletproof system. Remember, how I talked about the fact that under Windows the parent process owns every right to the child process, even in a limited account? We can use the same mechanism to expand our privileges beyond what was intended as shown in the following scenario:

• Process X has a given privilege we need.
• Process Y wants to gain those privileges. It launches a new instance of X, becoming the owner of the instance.
• The privilege is automatically granted to X by BeyondTrust
• Now Y, using its privileges, can insert arbitrary code in the instance of X

The probability of an automated tool figuring out such complicated chain of actions (or even figuring out which programs it needs to use to gain the needed privileges) is of course very low, however in the case of an insider threat this attack is still feasible. Of course there exists much simpler attacks, which can leave the system exposed even with a slight misconfiguration (for example, the fact that the open / save dialogs are complete file manager solutions, which can be used to move / overwrite files from inside a privileged application). The point I'm trying to make here is that there is no silver-bullet for security.

PS I couldn't try this attack, because although they have a free version on their website, it kept insisting on having the computer in a domain, which I won't set up for the sake of this program. Anyway, if somebody has already configured this program, please perform the following test and report back with the result:

• Pick an arbitrary executable (telnet.exe for example) and assign it some special privileges.
• Download the very nice user mode-debugger, OllyDbg and from a limited user account open telnet.exe for debugging.
• Use ProcessExplorer to verify that OllyDbg doesn't have the special privilege, while telnet.exe does.

Three letter acronyms don't provide good security!

As a second part for my previous post, here is an other post where Deb Shinder gets it wrong (or at least emphasizes the wrong words): Security Mechanisms in Office 2007.

My problem is not with the post per-se (because admittedly I only saw Office 2007 in the Channel 9 videos), but with this particular phrase (emphasis mine):

These include a much improved password protection scheme that uses AES, built in support for Windows Rights Management Services (RMS), more user friendly digital signature support, the ability to force users to use the new, more secure XML-based file formats, cryptographic options for Outlook and more.

Repeat after me: three letter acronyms don't provide good security! Good security planning provides good security! I think that she falls here in the pit dug by many advertisers who put on their products things like 1024-bit military grade encrpytion and the like. Lets examine both of the claims in a little more detail:

AES encryption - simply by stating what encryption algorithm a product uses says (almost) nothing about the security of the product because it doesn't say how it is used (to be fair it says that at least the developers were smart enough not to try to come up with their own algorithm).

more secure XML-based file formats - more secure than what? The XML based file format is easier to read and to extract metadata from than from the proprietary binary blob which is the original file format.

In fact the new file format is nothing more than a set of XML files inside of a good old ZIP archive, optionally with a password. In fact the article should say: Office programmers learn from their mistakes (of trying to come up with their own encryption algorithm) and start using proven industry standard!

Biometrics is not the answer!

Deb Shinder is the resident MVP at Sunbelt Software. One of her posts caught my eye and I felt the urge to post about it: Passwords: A Thing of the Past? In it she advocates to use biometrics as a replacement for passwords. Here are my (not so positive - as you may have guessed) thoughts on it:

• The big problem (aside from false positives and false negatives) of biometrics is that they can't be changed. As soon as somebody gets your fingerprint, you really don't have any solution for it (you can't change your fingerprint).
• She also fails to mention in the article that biometrics doesn't give you any additional security unless the endpoint security is assured. Otherwise said: nothing in biometrics prevents an attacker to use a replay attack (because it's not your fingerprint / retina scan which is sent through the network, it's a set of bits generated from them which can be capture - most conveniently at the endpoints - and replayed easily). Compare this with a well-implemented token system where the generated data is specific to the time and the sum transmitted (in case of a bank transaction for example), so capturing and replaying it would be useless.

In conclusion: biometrics is nothing more than a hyped version of the remember my password feature found in all the current browsers. It provides virtually no added protection over passwords and is purely a convenience enabler. (I must mention that there is one situation where it has added value over password: when protecting against the threat of someone watching you as you type your password)

Update on the Month of PHP Bugs

The month is nearing to an end (but fear not, next month we will have a month of MySpace bugs it seems), and here are the latest developments:

• Two bugs using which you can bypass the open_basedir restriction. They are in the user-contributed PECL modules, so there is a chance that they will be fixed before a PHP update. The bad news is that this agains shows that running on a shared server provides minimal security and you really should go with your own server.
• Some local code execution vulnerabilities! What this means is that anyone capable running PHP code on the same system (virtual or otherwise) can escape the PHP sandbox and directly run binary code! This means that any built-in PHP protection (like disable_functions or open_basedir) become useless! Also, remember that if your scripts (or other users scripts running under the same account - in case of a shared hosting) contain a remote include vulnerability, the attacker doesn't even have to have an account to run arbitrary PHP code!
• A vulnerability to activate register_globals, even if it has been deactivated from the php.ini (or .htaccess). As it stated in the advisory:

  The danger of this vulnerability is that nowadays many scripts try to protect themself against register_globals being activated by warning the user that it is activated, by refusing to work while it is activated or by trying to undo it, when it is activated.

  However when this vulnerability is exploited the script is unable to realise that register_globals is activated (without dirty tricks) and therefore believes it runs with register_globals deactivated.

  The solution (when you code PHP) is to properly initialize variables before using them (and not relying on them havin the 0 / empty string / null value).
• An error in the unserialize code. This can be triggered remotely if the script uses serialized data to pass state information between script invocations. Fortunately this is only an information disclosure vulnerability.

The conclusion seems to be that PHP is completely inadequate to run any external-facing web-services (which is a real shame given all the useful applications developed in it). As a mitigating measure one should move away from shared servers and implement multiple layers of security, like:

• An application firewall like mod_security
• A firewall on each host, with proper rules like (a) not allowing the host running the webserver to be contacted on any other port than 80 or 443 (many shellcodes open ports and listen there for connections) (b) not allowing the host to make outbout connections (this protects against reverse shells and bots which use IRC for command and control) and (c) only allowing connexions to back-end hosts (like a database server) from known sources (like your webserver).
• Use different (and long) passwords for different accounts so that one compromised password doesn't result in further compromise.

How not to get your application signed by AV

Disclaimer: these are my own opinions and they do not necessarily reflect the opinions or policies of any of my current or past employers.

There is a class of applications which can be categorized as greyware: programs which can be used for both good and evil. A few examples (in no particular order):

• nmap, the most famous network scanner: it can be used during a security assessment or it can be used by an attacker to search for possible attack targets.
• VNC servers, and other remote control software (RAdmin for example): both legitimate users and illegitimate users can install / use these software.
• FTP servers: can be used to share files knowingly or unknowingly (if installed stealthily by an attacker)
• Password enumeration tools: can be used for forensics for example, or to steal passwords.

These few examples already demonstrate that there are many shades of gray out there - so to speak. Philosophically you can argue that software isn't good or bad and that it becomes one way or the other during its use. However AV software isn't HIPS, it is intended to give a verdict before the particular piece of code runs. As such during analysis the virus researcher must decide if there is a reasonable possibility that this piece of code can be used in a malicious manner (of course if it's clearly malware, it will be signed as such).

To give you an example how such an attack would work, imagine the following (very real) example: a set of commercial tools (probably cracked version of them) packaged together in a self-extract archive which contains an installation script. Many archiving products offer the possibility to have some kind of script automatically executed after extraction and there is malware out there which uses installation products directly (like NSIS or Inno Installer). The package includes a commercial keylogger preconfigured to send the capture keystrokes to an e-mail address under the attackers control and a commercial FTP server set up to share the C drive for example with a preset password on a preset port.

One can argue that all of the code used here is not malware (even the installation script included in the self-extract archive can be part of a one-step install package put together for some particular - benign - purpose). The fact that this package is malware can be only determined either by examining the source of it (if it was spammed out to a million people with a misleading message or downloaded by using a browser exploit) or the context of the usage (ie. asking the client if s/he knows about these programs and if s/he agrees to them running).

This situation has no clear solution: only detecting the package provides no proactive protection and is mostly useless (because many times it is set do delete itself after execution and what you want to detect are the dropped programs) and detecting the particular programs (this sentence seem to have a lot of p's in it :-)) means that legitimate users who knowingly want to use these programs will be annoyed by the detection.

The current trend in the industry is to err on the safe side. Applications with missuse potential will usually be put in a separate category (like Possibly Unwanted Programs) and the prompt displayed by the realtime scanner will differ in the description (possibly also in the design) and in the offered options (which in a clear malware case are something like delete / quarantine and in such cases they are something along the lines of allow / deny / always allow).

On the flipside many users are annoyed by these prompts (in a good case) or don't read the text of the prompt at all and assume that the software is infected by a virus!. This can cause headaches and additional support costs / lost revenues for the software vendor, which usually blames the AV software as the first response.

While I don't know any silver bullet solution to this problem, here are some tips on how to avoid making your software look dubious:

• Don't use an executable packer! They offer minimal protection against crackers, the people who are using an illegitimate version of your software most probably wouldn't use it if it wasn't free for them and the more agressive packers (like the ones detecting Virtual Machines and/or debuggers) makes your program look dubious. Not to mention that some packers insist on loading a driver for unpacking purposes, which: (a) makes the clients system potentially less stable - in kernel mode one wrong move and you brought down the whole system (b) limits the use of your software - people running with limited privileges (which is a good thing) or on non-standard hardware (like x64 systems) might not be able to use it and (c) reduces the performance of your application.
• Along the same lines: don't try to detect Virtual Machines and/or debuggers! Most of these detections can be easily overcome, but they can lead to believe anyone looking at your software that it has some hidden purpose and/or doesn't want to be analyzed (Virtual Machines are often used during analysis because they serve as a sandbox environment and can be easily bought back to their initial state).
• Don't put executables / libraries in the windows / system directory unless you absolutely need to! Your program files have a very well defined place: the program files directory!
• Follow conventions! Use the documented ways to register at start-up and use descriptive names for your registry entries!
• Create a version info for all of your executables / libraries, preferably with a text that includes a link to a website where the purpose of the program is explained!
• Don't use encrypted strings in your application! They can be easily broken (since the idea is that your application needs to decrypt them at some point, meaning that anyone looking at your application can simply run the decryption routine included in it) and make it seem like your application needs to hide something!
• Don't overdo protection of your program! Example: some chinese messenger applications use drivers to protect themselves. Ignoring the fact that you cut off some part of your users (who run as limited user or use a possibly unsupported platform - like Vista or WinXP x64) and endanger the stability of their system, you make your program look fishy, especially in this day and age where almost every semi-advanced piece of malware tries to include rootkit technology.
• If your program works from the command line, make it such that when ran without any parameter, it displays the help, which should include a link to your site. This gives anyone looking at the program a good idea what it is about.
• Don't add any functionality which makes it easy to automate (like running it from the command line). Use a GUI interface. While this might be hard to do sometimes (because many of your more advanced client expect to be able to script the functionality of the program, consider it. Not providing an easy way to automate your software makes it a less desirable target to be included in malware bundles.
• Update: avoid using the services of individuals / companies who are known to host malicious files / send out spam willingly. Two examples would be: the estdomains registrar and Chinese / Russian / Romanian hosts. Disclaimer: I know that this is a sweeping generalization and that in all of these countries the number of legitimate businesses far outweigh the illegitimate ones. Also, just recently a report came out identifying the US as the primary source of attacks / malware / SPAM. The perception is still there however and most probably a little money saved can cost you a lot in sales later. Hopefully we can clean up our act and gradually remove these stereotypes.

One thing I must say is that even after following these guidelines the software might end up in the special category I talked about earlier if it has a miss-use potential and probably has already been miss-used. In this cases you don't have a magic solution, because they are not misrepresenting your product, the customer is not reading the warning. The one thing you can do (besides explaining the situation to your client) is to give them instructions on how to except the given executable from scanning (most AV products include options to except certain files / directories from on-access verification) - by downloading a trial version of the scanner and installing it on a test machine or a VM (Virtual Machine). You could of course advise them to contact the AV company for support, but probably this would considerably reduce your clients satisfaction.

Of course if an AV clearly mis-categorizes your product (for example it says that it is a trojan or worm), most probably it is a honest mistake or a generic detection gone bad. In these cases you can most likely get the vendor to fix the problem in a short time, because it helps them to improve their customers satisfaction.

Update: check out the post on the Authenium blog about the same topic.

Mobile malware - hype or not?

I'm not entirely dead yet, just very busy :)

Anyway, I came across this blog posting (Mobile Virus FUD) which in turns references this article about Kaspersky Labs (not the one at heise security as I stated - erroneously - before). Before we continue, a disclaimer: the views and opinions expressed here are my own and are not representative for any current or past employer. I have no relations with Kaspersky Labs. Also, I'm not an expert in mobile devices per-se and never did development for them, but I have some background in low-level logic circuits (like FPGAs).

Back to the topic: the article referenced ask the question how much of the danger presented in the media is true and how much is hype? I have to say that I despise hype and half-truths meant to scare the public into acting a certain way very much (just look at the title of my blog) and in the short term I have to agree with the posting: it is mostly hype and currently it has a very low possibility of affecting people. However, this being said, this issue has a very great potential to become a big problem in the future. The reasons being:

• As far as I know many mobile OSs sacrifice a well defined security model for simplicity and performance. You don't have limited user accounts, you are always running as administrator.
• Further more, many of the processors used in such devices lack the proper hardware basis - again, for cost and performance reasons probably - to implement such a security system (this is not to say that you can't implement a very secure system in software alone - just look at Singularity, a research OS written in C# which relies entirely on software to enforce the security - but it is a lot harder)
• Finally, the security industry hasn't managed to convince all the people that they need security products or to inform them on how to use them properly (like updating regularly). It will be even harder with smart-phones since many people will say it's just a phone, why do I need to have to buy X for it?
• This same lagging can be observed in the patching area: no framework for patching existing phones is currently available.

In conclusion, the situation is somewhere at the Win9x level: every program runs with system wide privileges, no automatic method for patching system flaws and very low user awareness. It isn't a problem currently, but if the right financial motivation appears (like these phones getting widespread and containing many sensitive information), it has a git potential to become one.

TT - Treacherous Technology

So, after a failed upgrade to Ubuntu 7.04 Feisty Fawn I was left with no choice but to boot into my Windows 2003 partition. (To Ubuntu's defense: 7.04 is clearly marked as beta software and I was doing the update on my own risk). Just to be clear: this Windows 2003 SBS is a 100% legal one, which I got as gift from MS for participating on last year Imagine Cup. I installed it and quickly forgot about it after I installed Ubuntu.

Now that I had to use it again (although it will be only until I make some time to reinstall Ubuntu), I got hit by a curious problem: it was shutting down after 1:30 of use. My first reaction was that somehow a malware got installed on my system, but that wasn't the answer. The solution to the quiz was in the eventlog and read like this:

The server was shut down because it did not comply with the EULA. For more information, contact Microsoft.

Now admittedly I never read the EULA and hacked Windows Activation (because I don't want to send any data to MS), but this was a little intriguing. A quick Google search turned up this Knowledge Base article: Windows 2003 Small Business Server Shuts Down Unexpectedly; Events 1001, 1013 and 1014 are Logged. It turns out that I didn't install the AD server on the machine... This really seems over the top. Admittedly it is MS's right to sell their software under whatever license they want, but this is just one more step which distances me from any MS solution. And by the way - they state that Win2K3 SBS can be used with a maximum of 5 clients, which is totally artificial. I can get how different product features can go in different versions of the product (like Basic, Home, Pro, etc), but artificially limiting something is just plain wrong.

Fortunately there is a happy ending to the story: I just used the SysInternals ProcessExplorer (which now ironically is owned by MS) to suspend the SBS licensing process (you can recognize it either after the name of the executable - sbscrexe.exe - or its description - SBS Licensing Service). You could also try killing it, but most probably Windows won't react well to something like it (they treat Licensing as a key component, for example on Vista your box will die if you try to mess with it)

PS. A bonus tip - for salvaging data off your ext2 / ext3 drive (yes, it will work with ext3, because if is backward compatible with ext2), you can use either the plethora of free drivers which can mount ext2/3 on windows (I would recommend this one, because I used it in the past and had very good experiences with it), or a program called explore2fs. To recover your Firefox 2 session, just copy the file sessionstore.js from the directory /home/<your user name>/.mozilla/firefox/<a directory with random name>/sessionstore.js and either extract the links manually or drop it in your Firefox installation and restore the session.

A new contest

I know that it's a little bit late, but hopefully some of you may still find it useful:

The nCircle VERT challenge #1

Month of PHP Bugs (MOPB) update

As the days pass by, new vulnerabilities are disclosed on the Month of PHP bugs. An important (and very useful) change is that markings have been added to the main page which show the vulnerabilities that are not addressed in the latest (5.2.1) release and the ones which are not directly related to PHP (for example there is a bug which lets you bypass mod_security). The new (since my last post) vulnerabilities break down as follows:

• 1 mod_security bypass - present in the latest release version (2.1.0)
• 1 bug in the PHP4 Ovrimos extension - disable the extension since it seems to be particularly bug ridden (also, remember to enable the minimum set of extensions which is necessary for your code to function)
• 1 arbitrary code execution in the PECL ZIP - disable this extension now! Given that this is not part of PHP Core, we might see an update sooner. On the flip side, arbitrary code execution is bad, because if you (as most of the people) load PHP as an Apache module (for performance reasons), the current PHP interpreter equals the current Apache process, which can contain sensitive information (like SSL certificates!)
• 2 memory read exploits - the first one (not patched in 5.2.1) allows a limited range memory read, but still enough to read some special values (like stack canaries). The second one (which is luckily addressed by the latest release - one more reason to upgrade!) allows arbitrary memory read in the current process (which is Apache if PHP is loaded as a dynamic library).
• The PHP filtering extension also had it share of problems with 2 bugs, which could result in not 100% sanitization of the input, luckily both are fixed in the latest release.

My opinion / advice: in the light of these vulnerabilities (and other, much older issues), shared servers with PHP are almost inherently impossible to secure. Go with a separate server or at lease a Private Virtual Server if possible at all. Apply layered security. One of the advisories said:

This bug shows one of the weaknesses behind the ext/filter idea. Whenever there is a bug in the filter implementation all applications that make use of it are vulnerable and can only be fixed by upgrading the PHP version (because the filter extension is static by default).

This is true, however you shouldn't draw the conclusion that these solutions are useless (or that mod_security is useless, just because a bug was found). Such reasoning misses the point. Lets say that normally your system is vulnerable to X exploits. After you install some security add-on (like mod_security of Suhosin), your system is vulnerable to Y exploits. As longs as Y is less than X (and most of the time it is considerably less), it is worth considering the deployment of that product (and I emphasize considering, because you must think about many other issues before deploying such products, like how many applications / scripts will it break and how much time does it require for fine-tuning). And just because Y is not 0, doesn't mean that you should avoid using the product and stay vulnerable to a much larger set of problems.

Finally, you should consider going the FastCGI route to separate the script interpreter from the web server (in fact you should go the plain CGI route, but this may yield performance which is unacceptable).

A long required update

Hello all. Again I find myself swamped with work, so I'm a little MiA. I still will try to keep up the blogging and bring you (hopefully) useful information. So here are some links and my opinions about them:

The McAfee lab guys think they're smart. And most probably they are. However the above mentioned post struck me for its lack of professionalism.

On a similar note on the Authentium Blog there is a philosophical post about the Internet and democracy. Before I write my comments, a little disclaimer: I'm a technology guy, without any background in philosophy or political science (or history for that matter), and it may well be that I'm beating a dead horse here with these thoughts. Now back to the matter at hand: in my opinion democracy only works in matters where there is an overwhelming majority either (a) believing the same thing or (b) not really caring about the issue. However, when there are two groups which are of similar size (lets say 60% - 40%), even though you technically have a majority, you will have very difficult time applying the winners perspective. And this is why (IMHO) democracy driven approaches will fail on the Internet. Because the medium itself empowers everybody and people are no longer bound by psychical boundaries. Even if there is very little opposition to an idea in country A, if there is a strong opposition in country B, it may also prevent passing any resolutions concerning international matters in country A (if such an international democracy gets introduced). An other problem would be that democracy tends to work better on small scale, and as the scale of things increases, it tends to drift away from the original idea of the rule of the people. This is a problem of information flow in both direction: many people - myself included - do not always - or should I say most of the time - know about the grand scheme of things and how supporting one or the other candidate will influence our everyday lives. Also, many representatives don't have an clear enough picture about what her/his voters want or would want or act out of self interest. Having all these issues in mind I think that we won't see something like an Internet governance for a long time.

Security Update - MOPB, DMA, etc

First just a fun little post on Slashdot which debates what /etc stands for

Now for the security related stuff:

The Month of PHP Bugs continues with two new vulnerabilities. Fortunately these bugs were disclosed to the PHP team beforehand, so updating to the latest version solves them. Also, one of them is in the WDDX extension, which seems to be in a particularly poor shape, and you might consider disabling it (because in my 7+ years of PHP programming I've never seen code using it and had to look up myself what it stands for). Of course we all know that all non-used extensions should be disabled, but my advice was given from the point of a shared hosting provider whos goals include providing her clients with as much functionality as possible. Then again these (and most probably the coming) vulnerabilities show that once you run someone elses code (be it in whatever high language you may think is sufficiently sandboxed), you take on risks (and big risks with PHP).

Joanna Rutkowska held her presentation at BlackHat (slides available) about bypassing hardware-based memory readers. The gist of it is that (a) you can map certain memory ranges to go to I/O ports rather than the memory (the so called Memory Mapped I/O) and (b) the DMA controller goes through an extra chip while reading compared to the CPU. The attack is to reprogram that extra chip, resulting in showing different results to the data acquisition card than to the CPU (effectively hiding any code the author wishes). My opinion: this is certainly interesting, but can easily fixed by the vendors of the memory imaging cards. Then again, to perform such manipulations, the code must be in ring-0 (or kernel mode) and then it becomes an arms race (for example you can use the CPU debug registers - with some restrictions - to watch the I/O as show by this recently published article on rootkit.com). Again, rootkits and anti-rootkits are irrelevant, and people (programmers, system administrators, policy makers) should try to implement the policy of least privilege where possible.

And finally, there is a post over at Arbor Networks which talks about how every type of file (including RTF, PDF, DOC, etc) can be dangerous. It seems that the days of reject executable attachments are gone. What can we tell our users? In my opinion we should stick to the old message (do not open executable attachments) for two reasons: to be consistent and because this filters out a large portion of the nasties out there. As for these other issues: patch, patch, patch.

The progress of MOPB

The Month of PHP bugs is progressing nicely and the counter is up to nine (at this rate - supposing that we have a linear progression - we will have almost 70 vulnerabilities!). The new ones repeat the same patterns as the previous ones: they can be mitigated in environments where a single user controls the server, but in a shared hosting environments they can present serious problems (for example this bug - MOPB-05-2007: PHP unserialize() 64 bit Array Creation Denial of Service Vulnerability allows to very easily DoS the computer if it's running an older version of PHP on a 64 bit machine).

My advice remains the same: forget shared hosting (both as a client and as a Service Provider) and patch, patch, patch - also consider things like Suhosin and mod_security. I know that (especially the later) can be a pain in the rear end to configure, but the alternative - being owned or DoS-ed out of existence - is by no means better.

PS. This week seems to be a bad one for PHP security since the distribution server for Wordpress (a popular blogging platform written in PHP) was compromised - my respect to them for saying cracker, not hacker - and contains a backdoor. Via Slashdot.

What the market will bear

Very frequently I see the idea that capitalism (or market economy) will somehow ensure that the end-users get the best possible products with the lowest prices. Yet many times common wisdom contradicts this. How is it possible? (Disclaimer: I'm no economist, these are just some personal ideas and observations).

Personally I think that there are two causes of this phenomenon in the software industry: vendor lock-in and the over focus on short term profit.

Vendor lock-in can mean several things, but usually it refers to data lock-in (where it is very difficult to extract the already introduced data) and/or interface lock-in (where the staff has learned the current interface and it would take serious time - mind you, many of these people are not tech-junkies - for them to re-learn a new interface - which also may not be the most intuitive or usable one).

Concrete example: on the Romanian market there are several accounting products. All of them I've seen so far are poorly written (some of them are still based on an MS-DOS version of FoxPro for example). But the software vendors are not the only ones to blame, mind you, because legislation here changes almost daily (I think we hold the record for a law which existed for less than 48 hours!). Also, an other aspect of our legislation system is that after the law appears, you have to wait (on average a month, but longer periods are not unusual) until the application methodology appears. Two things follow from this: (a) the law is so confusing that nobody knows how to apply it without further clarification and (b) you can be fined because you didn't respect the law, which nobody knew how to apply! Anyway, back to the accounting software: the one which is accepted to be the best is written in Delphi (nothing wrong with that) with a look which reminds you of the first applications written for Windows (big, clunky buttons with an red x or green a check mark on them for yes and no and so on). The back-end is based on BDE (Borland Database Engine), which, although it has good integration with the programming language, it completely inadequate for storing anything even remotely complex. No foreign keys, stored procedures, etc. It has been discontinued for a reason. The business I'm talking about is a small-to-medium one, and even there it takes around 10 minutes to bring up some reports. The company selling the product tries to blame this on the network, but this is a laughable excuse (all the computers are connected to the local LAN with 100MBit speeds). And did I mention that the database re-indexing must be done manually and there is no command line tool so that it can be scheduled! If you thing that this is something for the DailyWTF, you're right. But it gets even better: as I mentioned earlier, the laws change almost daily here and accounting products need to adapt. So, after yet an other law change, the company managed to produce an upgrade which theoretically respected the law. I say theoretically, because their clients never got to use it, since it broke horribly when installed, taking down the whole accounting system. And mind you, these are the best on the market!

The other example I want to give is not so clear-cut (because of government involvement you can make the argument that it's the fault of bureaucracy and corruption not a failure of free marked): a local company (which again won't be named to protect the guilty) prides itself with producing an European level e-Learning system (as a side-note: European level seems to be a keyword around here lately). This given company also buys full page ads in many of the local computer magazines where they write long texts about how they won different ads. I never used the system, but was blow away just by the specs: written in Java with an Oracle back-end. Now I'm sure that many of the schools have such huge amount of data that it couldn't be handled by PostgreSQL <sarcasm>. Nice way to sell some more Oracle licenses!

A final example (again, this is somewhat irrelevant, since I'm talking about the government here): check out the programs published by the Ministry of Finance to help companies making their monthly reports. They look like some VB apps written by 14 year olds who just read the first half of a how to program in VB book. And most probably big bucks were paid for them, much bigger than I make in a year.

The point of all this rant is that pure economical forces won't create the needs for technological excellence, or create it very slowly (and I mean very slowly - think decades). One of the factors is that if you are just a little bit better than the others, you can dominate the market. And that little bit better can be your bug ridden antique FoxPro based accounting system! An other problem is that customers don't know that it can be done better, nor do they have a way to find it out, since there is no better solution! So forget agile programming, test driven development, source control and all these nice things you only hear about in podcasts and say hello to big bucks made by selling cheap software!

Month of PHP bugs started

The Month of PHP bugs started off today with not one, but three bugs. Two of them can be protected against by using Suhosin (you might accuse the guy of some grey area marketing - but you can't since his product is both free and open source) and the third by upgrading to PHP5 (because it is a PHP4 only vulnerability).

The situation currently is: if you are running on a dedicated (virtual) server, you don't have anything new to worry about (since supposedly your programmers don't intentionally try to crash your webserver). On the other hand if you are running (or using) shared hosting, be worried, very worried. One malicious user or one easily hackable PHP script can make your server an easy target for DoS attacks with these bugs.

It seems rather curious that the PHP developers were against the fixing of these flaws (if you can believe Stefan Esser, after all you have to take the word if all involved parties with a grain of salt), because it is something that Perl is doing, most probably for many years.

If all the bugs stay in this area, people running / using dedicated hosting will be relatively safe (as safe as were until now). The clients of shared hosting companies should try to migrate anything remotely important or confidential over to dedicated hosting if the given shared hosting company provides PHP (and most of them do, except for the ASP ones) or at least convince them to install Suhosin (which they probably won't). Don't even try to convince them to use mod_security, because while Suhosin shouldn't require many configuration and most probably won't break anything for anybody, this certainly will.