Luigi Auriemma

Just curious how does this actually works? Or is there no release of how to use this bug. I saw you made the patch for ventrilo and it had me curious anyways nicely done with the patch and well keep up the great job luigi.

Are you asking how to apply the patch to your ventrilo client?

lol no, I was asking how you would go around to making someones ventrilo crash. I already know how to apply the patch, I was going to do it earlier but I decided not to just yet lol wanted to see the bug in the works.

You cannot "crash" the server with this all it will do is disconnect who ever is in the channel you talk in. On the other hand I posted yesterday about something similar I was playing around with the voice packets and I'm not sure what I did but the whole server(Console) just froze, but I guess Luigi found this bug instead. I test this bug on a local server

What I got to work was;

-talk in a channel with my bots, all the bots crash (sometimes not all of them)
-private chat a bot and talk to it, the bot crashes
?this one I wanted to try but forgot how, you let the whole server hear you (in every channel) But I cannot remember how to global broadcast on my server. D:


I was going to check this too but this is a "bufferoverflow" I think? so I could make it execute shellcode such as calc.exe ?


And this is 100% off topic but here it goes anyways..no point in making a post about this

Today in class our teacher told me that to make stronger security algorithms I should use prime numbers such as ..7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 Does anyone know why prime numbers = better security algorithms? I have no clue why it would make any difference.

Told you it was 100% off topic :D

are you referring to the ventrilomemset bug?
no it's not a buffer-overflow, practically it's the same of placing tons zeroes (specified by the attacker) in a buffer.
the problem is that this allocated buffer which should contain the uncompressed voice data can be too small to contain all these bytes or just unexistent (address 0x00000000) and so the client crashes.

How would I find these in Olydbg/cheat engine/hiew


OFFSET FROM TO
00046064 8B 33
00046065 56 D2
00046066 08 4A


I search for the offset and nothing comes up. I know I'm doing something wrong.

I want to edit them in real time to see if there is any other effects.

you must covert the file offset to rva offsets:
http://aluigi.org/mytoolz.htm#quickrva

Is there a better documentation on how to use this tool?

EDIT: I put 00046064 in the search box and ventrilo.exe is loaded should it show something?

- launch the tool
- drag'n'drop ventrilo.exe on the quickrva's window
- put 46064 in the "file" entry on the left
- the rva offset will be displayed in the entry above it

Thanks I didn't understand how to use the tool at all before. Anyways I found out that;

To have the same crashing effect all you can do is change this



To this;



Why did you add the other line(00446C66 - dec edx) when the single change is enough? This is on a 3.0.5 client. I'm just curious.

Oh yeah I found this to I always wanted to do :D

All this does is make you microphone turn yellow when you talk BUT no one can hear you ): (If anyone knows how to turn my microphone yellow instead of green and still allow people to hear me please share the info) :

Change;



To this;

it's a bad move in general (not in this case but generally) replacing "mov edx,[esi+08]" with "dec edx" except if you are 100% sure that edx is ever (and in any case) 0x00000000 at that point.
then when you have the needed space it's useless to complicate your life, use all the 3 bytes instead of leaving 2 useless nops so that it's also easy to port the patch on other possible versions if necessary without the need of checking if the register is already zeroed or not.
so nothing important, it's ok also to use only "dec edx" in this case.

the funny thing about the yellow microphone is that in my testing code (a modified ventrcon) it's ever yellow and seems to be related to the valid or invalid voice stream and by the lack of voice packets between the opening and closing of the mic.
indeed when you decrease esi you generates no voice packet because the size of the packet is multiplicated by 256 (if [esi+4] is 0x34 it will become 0x3400 when esi decreases) and there is a check at offset 00446c9c which drops the outgoing packet if such size is bigger than 0x1000.

with ventrilo_proxy you can see everything.

oh I forgot to say that yesterday, during my quick test, I found also another bug with an effect similar to ventrilomemset but affecting only one type of codec (not the default one).
I will release the advisory tomorrow.

and also "OR EDX,FFFFFFFF" was ok and fits all the 3 bytes

The other bug is with the speex codec right?


And for that yellow microphone do you think it would be possible at all to make it light up and still transmit voice, such as the green microphone/ or maybe keep the microphone red and still transmit? If you think it can be done I will go do a investigation to try and figure it out.

You said something about 00446c9c is there a easy way to patch that so it does not drop the packets? If there is then



would let the voice stream get thru while being yellow correct?

What debugger do you use, is it IDE?(I forgot the name)

yes the bug is with the speex codec which already has some problems in itself (so I talk just about the original Speex codec) but "seems" that it's the wrong usage in Ventrilo the major cause of the bug (so Ventrilo is responsible between 50% and 70%).
now I check another thing to exclude code execution and then the advisory will be released on http://aluigi.org/adv/ventspeex-adv.txt

for the yellow thing I can't help much and doesn't seem a thing which deserves attention.

for the debugger use ollydbg: http://www.ollydbg.de

I believe this will effectively crash all but the largest of Ventrilo servers.

Did you test it already with the binds? I never use the bind because I have NO CLUE how to use them.

Anyways ill make a few channels and test it on my server and report back what happens.

Ok so I made 3 channels each with a bot

2 of them had no password were 1 of them did

when you are admin and use that global bind you make all the bots disconnect

when you are not admin you make every bot in "open"(not locked) channels disconnect

Also I found out if I had 1 bot on "mute" so it cant hear anything when I tryed to disconnect my bot it would not leave, it seems that muting stops it.

EDIT: And here's a way to patch it if your hosting company does not let you apply patches to your server. All you do is mute everyone and force them to use a account with a password, then if you see ventrilo crash you know who did it then remove his/her account. Problem solved, unless Luigi releases a patch to fix the client, then flagship will steal his patch and force everyone to update to the new client. and not tell anyone about such vulnerability.

I've been dicking around with this for a while now.

Found out that specific servers will instantly temp ban you for 600 - 960 minutes when you alter the code and key in the mic on these servers.

Down here you'll see:



The instant temp ban comes from servers who run on a Linux 3.0.6 or WIN32 3.0.6 platforms.
While any other server on any other version of Linux or WIN32 (like 3.0.3 or 3.0.2 etc) so far does not instantly kick you for testing the memset.

Also worthy to note if you key in the memset on a 3.0.6 server in hopes to kick a bot or player, knowingly you will get temp banned , they will not recieve the corrupt packet before the server temp bans you and you will be locked out for 600-960 minutes.



You cannot get past a temp ban for you do not show up in the servers actual banlist. The server must be reset inorder for you to login to it again. I tested this by banning and unbanning my temp banned ip from another computer on a different connection to see if I could trick the temp ban, which failed. Reseting the server or waiting out the temp ban are the only options.

Thank you for your input. I'll keep you al updated if I find anything else.

It was silently patched in version 3.0.3.C


Flagship NEVER announces it's program vulnerabilities publicly.

It seems as though somebody has found a way to get past patch 3.0.6 since I experienced this overflow last night on that version of a ventrilo server.