When I was a teenager I remember using IRC a lot. I remember a short period of time that I wanted to have my own IRC server, So I looked for an IRCd and found UnrealIRCd. I’ve quickly installed it on my computer, and start sharing my brand new IRC server with friends (So what if I only had 56k connection?).

Today, I’m a bit older, And I’m no longer interested in owning the greatest IRC server of all times (It could be nice though). But still, I’ve decided to grab a look on that old open source project, security wise.

After a quick look, I’ve found a local stack overflow vulnerability while parsing the configuration file.

The bug

Apparently, when UnrealIRCd writes configuration error to the log file, it doesn’t check the length of the message. The vulnerable function is:

As you can see in line 8, the unsafe function vsprintf is being called with an output buffer of 1024 bytes. And we all know what will happen if the output message will be long longer than 1024 bytes… STACK OVERFLOW!

But can we control the log message? Yes we can.

How to exploit?

At first, we need to find a message in which we can control the whole message / part of the message.

After installing and running of UnrealIRCd, I’ve found out that the example configuration file throws several errors (I’ve downloaded the version with no SSL, and the example configuration uses SSL). So I got a nice message telling me one of the links (indicating the link name) got an error. I’ve decided to remove the SSL option from the link information and add a new option named “DiGMi”. Meaning, now in my configuration I’ve got a section which looks like this:

Instead of DiGMi I’ve written a lot of “A”s (like every good hacker does) and started debugging the server using OllyDbg. Sadly, I’ve found out that the server was compiled with security cookies so such a simple method for exploitation won’t work.

Overriding the SEH

Because I couldn’t just change the return address on the stack, I had to find another way to set the EIP register. A good way to do so in windows is overriding the SEH (Structured Exception Handler).

The SEH is located on the stack and it’s functionality is to tell the OS which code to run in case of exception. I’ve scrolled all the way down in the stack view in OllyDbg and found the SEH just sitting there, few thousands of bytes away, waiting to be override.

Can we override so much? – Why not? What’s limiting us?

So I’ve again added a lot of “A”s to my newly made option, and after 2266 of them I was just about to override the exception handler address, so instead of “A”s I switched to “B”s (just to mark the location.

But its not enough. We only changed the exception handler, but if no exception is thrown it won’t do us any good. so we need to throw an exception, how can we do that?

That’s right, Just keep on overriding until we fill the whole stack. And so I did. After overriding enough bytes OllyDbg finally gave me the wonderful message telling me:

(Remember thos 4 “B”s?)

Meaning now I can control EIP…

At that point I’ve stopped working on it because the next steps are a bit boring, and it should be easy enough to inject my own code to the software. Because it’s not a remote exploitation, it is just not interesting enough to continue looking into it.