Archive for the 'Vulnerability' Category

Do Not Detect Overflow With Overflow

Credits to a gweilo for the sharing below.

Integer overflow and underflow manifest themselves as vulnerabilities. Here is an overflow bug fired by Sir BugFinder. I assigned our fictional developer Sir FastFix ownership of the bug, and he jumped into the code straight.

First, look at this problematic pseudo-code snippet below :

SWORD param = 0;

while ( flag )
	param ++ ;
	//manipulate the flag value...

buffer = malloc(sizeof(BYTE) * param);

The param can increase definitely. No good. Sir FastFix quickly identifies the problem and sends me this code review below.

// sirfastfix: now uses unsigned.
UWORD param = 0;

while ( flag )
	// sirfastfix: code fix for overflow bug.
	if ( param > param + 1 )
		TRACE_ERROR("Overflow occurred at param\n");
		return E_UNEXPECTED;
	param ++ ;
	//manipulate the flag value...

buffer = malloc(sizeof(BYTE) * param);

Now, I have to review it. Let’s look at the changes.

  1. param is now checked with the condition (param > param + 1). Since it must be false, an overflow must have occurred if it is true. Intuitive.
  2. param is now unsigned using UWORD, and not signed SWORD. I find no reasons for negative buffers. A good move.

But, something smells stinky. Let’s think again.

  1. Why not use well-defined constants like MAX_INT, MAX_SHORT or MAX_LONG constants to check before incrementing param? Like MAX_INT – a < b ?
  2. Why the code to detect overflow is using yet another overflow to check?

Sir FastFix, I am not approving this code check-in. This fix is not going in anywhere into the source tree. Who knows what this overflow to check overflow can result in? Let’s write more solid and not college quality code, and not rushing to resolve the bug.


China is a Good Place to Pen Test

In the midst of crazy work, I breezed through certain websites and randomly injected some simple attack vectors over this month in China. I found several large sites that are vulnerable to XSS and SQL Injection.

Large sites including DangDang, Sina China, Sogou, Baidu, some of them fixed the problems after emailing them or maybe after reading the logs, too. However, the SQL Injection in DangDang remains unfixed and that is not good. I will not disclose here though ( you can certainly find it easily. It is just simple and buggy. )

To give you an idea of how big the sites above are relative to China, here are some analogies :

DangDang – Amazon

Sina China – Yahoo! News

Sogou –

Baidu – Google ( bonus, Baidu beats Google in China )

I guess I will have to find more time to play with these sites to look for more holes. But for now, I have tons of work piling up. Ouch. I have vacation today, in office.

More About the Characters Causing XSS in Opera

I talked about an XSS in Opera 9.51 as discovered by Chris Weber [1]. I talked with Chris and he hinted me something about the character encoding, which I certainly have little concept about it, and I found out why it is happening.

Except U+180E, U+180F, they are all associated with spaces ( The Zs, Zl, Zp categories ) [2] [3]. In fact :

U+2028 – Line separator in unicode 3.0
U+2029 – Paragraph separator in unicode 3.0

Different kind of spaces in unicode :

U+2000 to U+200A

U+180E is a Mongolian Vowel Separator character [4], and U+180F is a non-existent character. Somehow U+180E fall into the Space Separator category as well. For U+180F, I really have no idea how it happened. If you know what is happening, I really appreciate your sharing.

Well, quite a good lesson on international character sets, no? I really recommend Chris Weber’s blog [5] because it contains a lot of information on character encoding and web application security that you should not miss it out.

References :

[1] –
[2] –
[3] –
[4] –
[5] –

Interesting XSS In Opera 9.51

Bad things can happen when things are not treated as what they are. Consider the HTML tag below :

<img src=non-existent-link&onerror=alert(1) />

The browser should treat it as the following content :

<img src=”non-existent-link&onerror=alert(1)” />

Not too bad, right? But, what if the character “&” is treated as space?

<img src=”non-existent-link” onerror=”alert(1)” />

Not too great, our image tag points to something non-existent, and inadvertently triggers the onerror callback, and free javascript for everyone who comes along… in Opera 9.51. Credits to Chris Weber to the discovery.

This is the case when some character becomes a space character. ( No, the “&” character is just for easier interpretation. )

Here is a list of characters that is treated as a space character :

U+2000 to U+200A

The list of Chris Weber seems to be smaller, but the above are working as I tested it against with Opera 9.51 on Windows XP. So I am pretty sure those are extra. =)

I also tested on Firefox 3.0.1, Internet Explorer 7.0.5730.13, Chrome The vulnerability does not exist there. For Safari 3.1.2 (525.21), I *think* there are not problems because it passed some of tests, but I failed to run all the tests due to its serious performance problems ( guesstimating to be memory leak? ). More on that in the next post.

Reference :

Advisory : Attack of the Mongolian space evaders

Bypass Basic Authentication in Routers

A friend bought a router model GN-B46B of Gigabyte, and asked me if it is dangerous to expose the router to the WAN.

“Yes, of course, but you must have at least one point of contact anyway. By the way, if you cannot access the administrator page, the account name is ‘admin’ and password is ‘password’.”

Yup, I changed the password, Well, that was simple, as it was a creation of the year 2004. I searched SecurityFocus and immediately answered my friend’s question. No, I invented nothing. How did it happen?

The main page redirects to a login page secured by a HTTP Basic Authentication. However, the rest of the pages do not require the HTTP Basic Authentication. Here is the point, if you know the URL to the page that does certain function ( e.g. change password ), you can skip the login page and enter the URL to that page directly! The router site map is trivial to obtain, and I changed the password. Ouch…

This is old news, but such grave mistakes are still present out there. Time to check your own router!

References :

Blended Threat – Safari Carpet Bomb and More

It has been two weeks since the announcement of the Safari carpet bombing. In case you do not know, Safari has a very nice feature that allows web servers to put arbitrary files into your local computer without consent, and, according to Apple, that is by design.

Neat! Remote file management!

What harm could it bring to have junk files on our local system? We users have a lot of junk, don’t we? Three things that can be summarized :

1. A fake executable so unwary users click on it.
2. A malicious PDF like with vulnerability MS07-061.
3. Open IE7 or IE8 ( or possibly other software, more to that. ) and then get 0wN3d immediately.

Nitesh Dhanjani wrote about the carpet bomb. The core idea is that Safari will download the file to the default download location if it cannot handle the file type (Content-type). Internet Explorer and Firefox prompts the user in the same situation.

Now, add this with Aviv Raff’s findings on DLL-Hijack of IE7 ( and IE8 beta 1 ), they make an unaware download and an auto-executed file. The core idea is that IE7 ( IE 8 beta 1 ) uses the LoadLibrary API in Windows. The internal implementation is that it loads the first DLL found.

According to MSDN,

If lpFileName does not include a path and there is more than one loaded module with the same base name and extension, the function returns a handle to the module that was loaded first.

More to the DLL search order here.

Knowing this, and because IE does not load the dlls with absolute path and sign their DLL with public key, you can put the malicious dll with the same name in a place where IE will search earlier than the real path, then you get your private DLL loaded in place of the real one. That’s a DLL Hijack. Start IE7/8 beta1, you are 0wN3d.

Technical details, proof of concepts and credits to Liu Die Yu who pieced the puzzles together, and of course ultimately to the original vulnerability finders of Nitesh Dhanjani and Aviv Raff.

But wait. Like I said, LoadLibrary is an API of Windows, so it is not the problem of IE. Which means, for any application that uses a relative path and unsigned DLL is going to suffer the same fate of IE. Yes, you can’t really do anything with that for an arbitrary software you have. But think again, if someone can put a file into your computer without your consent, you are actually in great danger already.

To mitigate the Safari Carpet Bombing, follow this advisory.

But, again, what if the downloaded file is not dll? It can be a nasty MS07-061 remote arbitrary code execution in form of a PDF file. With IE7 installed, the shell32 will make way for the exploit as well. Sometimes with a lot of things on the desktop, the average person might not remember what is the file, and then open it …ouch! Get patched with KB943460.

Even more, if there is a nice .url icon with a familiar icon ( but with an extra arrow ) but pointing to a nasty URL…? You aren’t much better with this ending either. You can only be wary of what you click.

I really consider this Safari threat a nasty one. And it is a good thing I am not using it, and I for one don’t want to be 0wN3d, do you?