David Litchfield's Weblog: Look before you leap...

Tuesday, April 29th

Look before you leap...

So after publishing my paper the other day I've received a number of mails and comments from people who clearly don't quite "get it". Let me correct some of the more common comments and misconceptions.

1) You have to be highly privileged to do this.
No, you don't - in a multistage attack you can get what you need. To effect an attack, as described in the paper, you need to acquire the ALTER SESSION privilege. You can get this by exploiting another flaw such as DB04 in the April 2008 Critical Patch Update. This is a injection flaw into a ALTER SESSION statement. Furthermore, prior to Oracle 10gR2 the CONNECT role had the ALTER SESSION privilege.

2) You need direct access to the database to effect this attack
No, you don't. The attack described in the paper can be launched via the web through Oracle Application Server for example. Again, it's a multistage attack, but easily doable. Just use any one of the 5 bypass techniques I've published over the past few years and if the app server is patched against all those then look for an initial inject point point and use any of the facilitator methods I've described in the past.

3) This is simply second order SQL injection.
No, it's not, but it is similar. Second order SQL injection is where you load up a table with your attack SQL. At some later point this SQL is selected as data from the table and embedded in a dynamic query. The attack described in my paper doesn't deal with stored data. It manipulates the way the date and time is treated.

4) This paper is pointless as you should be using bind variables for dynamic queries, anyway.
Many developers only use bind variables when dealing with varchar data and input as they are known to be dangerous. They won't use bind variables when it comes to DATE or NUMBER data types. The whole point of the paper is to prove that DATA and NUMBER data types can be dangerous and that bind variables should be used.

5) This paper is most academic
No, it's not. This presents a potential threat. Developers should take heed.
David on 04.29.08 @ 12:22 AM GMT [link]

Thursday, April 24th

A New Class of Vulnerability in Oracle: Lateral SQL Injection

I've just released some research that demonstrates a new class of vulnerability in Oracle and how it can be exploited by an attacker. You can grab the paper from here: http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf
David on 04.24.08 @ 09:44 AM GMT [link]

Tuesday, April 22nd

Citius, Altius, Fortius!

Tonight, NGSSoftware won the Best Security Company category of the SC Magazine 2008 European Awards. Woohoo! Thanks to all the guys at NGS - it was thoroughly a team triumph smile
David on 04.22.08 @ 06:35 PM GMT [link]

Sunday, April 20th

I'm wrong. Supposedly...

I've been wrong in the past on a few occasions but never until last Firday was I wrong so honouredly. For a brief moment in Internet time I was wrong according to Ryan's facebook status. [Thanks, Steve wink ]

But I wasn't wrong. With all due respect to Ryan he misunderstood my post, and in this case, is the person who is wrong. He thought my post was defending public vulns counts as a true and accurate measure of SDL's success. My post wasn't about this at all and was simply a correction of something Pete said which I think know is not true. Boiling it down to the basics, as part of a much larger post, Pete said that Microsoft have paid the top researchers for their permanent silence which is why he thinks the public vuln count is down. My post said that this wasn't the case and that NGS can and do still release advisories - refer to both posts for the gory details smile

So I wasn't wrong after all, but anyway, let's tackle the larger issue: using public vuln counts as a metric for the success of SDL - can we or can't we - should we or shouldn't we?

To me the guts of these question are, at release time how many bugs are in the software? More or less than one would expect?

Here's a potentially true or false statement:

(1) Public vuln count is down meaning that there are (2) less bugs in release-day code meaning that (3) SDL works.

For those that think this is false it's because point 2 doesn't necessarily follow from point (1). For Pete, it doesn't follow because he thinks the researchers have been gagged. Even if this were true, which it's not (see my post), there's a problem - remembering that the vuln count is down what happened to the flaws that the researchers found but kept quiet? Either they were fixed or they're still in the code. If the latter, then why haven't they been found by other good researchers who baulk at the very idea of working for Microsoft and would love to see nothing more than Microsoft being embarrased or by made a name for themselves by getting out an advisory or two or sold them to Verisign or Tippingpoint's ZDI? Given that this hasn't happened we must assume the bugs supposedly found by gagged researchers were fixed silently and therefore the bugs are no longer in the code. This bring us to silent fixes. Silent fixes are another reason why some people (Ryan for example) think point (2) above doesn't necessarily follow point (1). We all know that given some patched software and some unpatched software hackers have learned how to find the bugs that have been silently fixed. A really juicy flaw would soon be found and end up in Metasploit or Canvas and I'm sure some modules have come through this route but nowhere near the numbers of flaws we'd need to make up the difference given the current public vuln counts.

Here's another thing about silent fixes and quoting from an email from Ryan: "we know [silent fixes] exist because the SDL requires that SWI [the MS internal security team] looks in adjoining areas for code dependencies and those are fixed but never documented [publicly]."

This is true. Whilst Ryan doesn't think it, to me this doesn't say anything bad about using public vuln counts as a metric for measuring the success of SDL; in fact it says something good about it. If SDL dictates that when a new bug is found externally, SWI looks for similar flaws then this surely leads to more bugs being found internally, meaning less are found externally, meaning the potential public vuln count diminishes. QED wink

But seriously, and wrapping this up for good (at least from my perspective), I don't claim public vuln counting is an accurate metric for measuring the success of SDL. It may or may not be accurate. However it is a measure nonetheless and shows the direction of the trend. There is an expectation that software developed under SDL will make the code in the final released product more secure and have less security bugs. Given that there are less bugs it is reasonable to assume that the public vuln count will be less, too. Lastly, let's consider this: if the public vuln count was up, even marginally, you could bet that everyone would be screaming from the rooftops that SDL was a failure. Given that most people (even Pete and Ryan) think SDL was a success, why is it so hard to believe the opposite?

David on 04.20.08 @ 05:51 PM GMT [link]

Friday, April 18th

Code Commandos, SDL and Metrics

Some people are arguing that you shouldn't/can't use publicly disclosed vulnerability counts as a metric to the success of the SDL. The major sticking point is best codified with a quote from Pete Lindstrom's blog:

"Microsoft has systematically hired and/or contracted with every one of their most vocal critics (and most seasoned bugfinders) to do the work behind the scenes and they don't count those vulns!"

This quote suggests a lack on understanding about what really goes on "behind the scenes" so this blog posting should hopefully make things clearer. Firstly, some definitions: a "pre-release product" is a product not yet shipped and at any given moment is under-going some part of the SDL process. A "shipped product" is a product that has undergone the SDL processes and whose code has been finalized. Now, the main aim of Microsoft's Security Development Lifecycle (SDL) is to deliver to their customers shipped products whose code is as robust and secure as possible. As part of this process there is a Final Security Review (FSR). This is where Microsoft hire an external 3rd party that are sent to give the pre-release product and code a beating up - code commandos if you will wink This FSR serves two important purposes from my point of view. Firstly, for each problem found questions are asked as to how the problem got through as far as it did. The answers to these questions allow the tools and processes behind SDL to be refined and improved meaning that, next time around, instances of the same class of issue shouldn't get so far again. The second purpose of the FSR, and most obvious, is to ensure that there are fewer security problems in the final, shipped product because they are found and fixed. In other words, the use of a FSR, which is part of SDL, means that the final product is more secure (by which I mean has less security flaws) than a hypothetical product that did not undergo the FSR.

Now down to counting vulnerabilities as a metric...

You only start counting bugs when the code has been finalized and the product ships. You don't start counting before - as it's a pre-release product undergoing security review. This should be obvious. So even if during the FSR of a given product a gazillion bugs were found then, with regard to the vulnerability count, this is entirely irrelevant because these bugs were in a pre-release product and not a shipped product and were found as part of the SDL process.

Now what happens if one of Microsoft's hired code commandos finds a flaw in a shipped product? I think this question is the root cause of Pete's and people of his ilk's lack of trust when it comes to vulnerability counting as a metric. His assumption is that these are quietly swept under the carpet and therefore not counted. Let me put him straight. This does not happen.

The reason it doesn't happen is two fold - firstly, NGSSoftware don't want to be or be seen as Microsoft lackeys and secondly Microsoft doesn't want to, or be seen to be, hiring lackeys. In the former case it would affect our independent status and in the latter it would undermine Microsoft's attempts to improve their software's security and convince their customers that this is the case. To that end, NGSSoftware asked for and was whole-heartedly given the right to continue to research and publish flaws in Microsoft products - shipped products - even those we have done work on when they were pre-release. Here are some MS alerts from the past two years that NGS have been credited in:

http://www.microsoft.com/technet/security/bulletin/ms06-nov.mspx
http://www.microsoft.com/technet/security/bulletin/ms06-aug.mspx
http://www.microsoft.com/technet/security/bulletin/ms06-jun.mspx
http://www.microsoft.com/technet/security/bulletin/ms06-mar.mspx
http://www.microsoft.com/technet/security/bulletin/ms06-jan.mspx
http://www.microsoft.com/technet/security/bulletin/ms07-apr.mspx
http://www.microsoft.com/technet/security/bulletin/ms07-jul.mspx
http://www.microsoft.com/technet/security/bulletin/ms07-dec.mspx
http://www.microsoft.com/technet/security/bulletin/ms08-feb.mspx

Furthermore, we don't do any MS sponsored reviews after the product has been shipped so if we find a security flaw at this stage there will be an alert.

Let me state this as clearly as I can. If I found a flaw in SQL Server 2005 tomorrow, I would report it to secure@microsoft.com, it would be fixed and an alert would be publicly issued. If SQL Server 2005 wasn't so secure, I would find one just to prove this - but I can't - because it is secure and SDL, every part of it, is responsible. So, when it comes to using publicly reported vulnerabilities in shipped products as a metric for SDL, rest assured, the results aren't as skewed as some would have you believe. I personally think, and I hope this blog posting will help convince others, that as any measure goes in an imperfect world, this one's "pretty good".

David on 04.18.08 @ 10:24 AM GMT [link]

Tuesday, April 15th

A bug in fread() could lead to a buffer overflow vulnerability

Back in October 2005 I isolated a bug in the MS C runtime fread() function which in certain cirumstances could lead to a buffer overflow. When a file is opened in text mode any carriage-returns/line-feeds (CR-LFs) are converted to CR. This is documented on MSDN. However, if the destination buffer for fread is bigger than 4095 bytes then the translation takes place in place and for each CRLF the buffer is shifted left once. Once all CR-LFs are converted no NULL terminator is set. So if a text file has the following contents

"16*CRLF"0123456789ABCDEF

what ends up in the destination buffer is

"16*CR"0123456789ABCDEF0123456789ABCDEF

However the return value for fread is 32. This can lead to an overflow - consider the following code:

#include "stdio.h" FILE *fd =NULL; char *buffer = NULL; int main() { unsigned int bytesread = 0; unsigned char name[36]=""; buffer = (char *) malloc(4100); if(!buffer) return 0; memset(buffer,0,4100); fd = fopen("foo.txt","r"); if(!fd) { free(buffer); return 0; } bytesread = fread(buffer,1,4096,fd); printf("Bytes read = %d\n",bytesread); // check that there are no more than 32 bytes in the buffer if(bytesread > 32) { free(buffer); fclose(fd); printf("Name is too long\n"); return 1; } strcpy(name,buffer); printf("%s\n",name); free(buffer); fclose(fd); return 0; }

Also, if 0x1A (Ctrl^Z) is encountered then fread returns the number of bytes up to 0x1A even though the number of bytes in the buffer is longer.

Now this is not going to turn into a class of flaw like format string bugs or anything, of course, but the lessson here is don't trust the return value of fread() as you could end up in trouble!

David on 04.15.08 @ 01:05 PM GMT [link]

Monday, April 14th

Are you sure? Surety, integrity, confidentiality and availability

Whilst researching for couple of papers I've had to write recently, I've been left with the problem of trying to suitably frame risk using "traditional" security models when it comes to client based flaws and felt these models were lacking.

The Federal Information Security Management Act (FISMA) [1] defines three security objectives namely integrity, confidentiality and availability. Federal Information Processing Standards (FIPS) 199 [2] defines three levels of potential impact caused by a security event - i.e. something that leads to a loss of one or more of the three FIMSA security objectives. As is, FIPS199 addresses well the potential impact to the system that actually exhibits the flaw but it's difficult to place a flaw such as cross-site scripting (XSS) in the FIPS199 framework. This is because an XSS flaw typically has no direct impact upon the system that exhibits the flaw - in other words it doesn't really affect that system's integrity, confidentiality or availability but rather it affects the system's clients (nothing new here, of course). The presence of XSS flaws in a system can lead to its users losing confidence in that system's safety - if they use it they could end up being compromised. If enough users feel that they're unsure about the system's security then the loss of consumer confidence can have a much higher potential impact than that derived from FIPS199's "formulae". It is apparent then that a new security objective needs to be defined: surety. Surety can be defined as a degree of assurance or confidence as to the trustworthiness of a system. A loss of surety then is a loss in consumer confidence that can lead to a loss of business.

There is a second aspect to surety to be considered. Whilst the presence of a security flaw such as a buffer overflow can affect a given system's integrity, confidentiality or availability, to the vendor of the vulnerable software the potential impact is a loss of surety in the software. As an example of this, consider Microsoft's Internet Explorer (IE) and Mozilla's Firefox [3]. Rightly or wrongly, as new flaws are discovered in IE more people opt to use Firefox instead - it is perceived to be more secure and thus has greater surety over IE - consumers feel that they're less likely to be owned when surfing the Internet if they're using Firefox instead.

Anyway, back to the papers I mentioned in the intro to this blog entry. When I get around to putting them out, when I start spouting off about a system's surety in them, you'll now know what I'm on about smile

[1] FISMA
[2] FIPS199
[3] Usage share of web browsers

David on 04.14.08 @ 05:22 PM GMT [link]

April 2008
S	M	T	W	T	F	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30