full-disclosure - Re: Buffer-overflow in Ultr@VNC 1.0.1 viewer and server

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20060405180021.37d10389.aluigi@autistici.org>
Date: Wed Apr  5 17:01:19 2006
From: aluigi at autistici.org (Luigi Auriemma)
Subject: Re: Buffer-overflow in Ultr@VNC 1.0.1 viewer and
	server

jalvare7@...astur.es wrote:
> Could you confirm my impression that the server vulnerability can only 
> overflow the buffer in 3 bytes?

Yes, the buffer is overflowed just by those 3 bytes plus the Windows
error message created with FormatMessage().

> Is there a way to exploit this for code execution, or would it
> be limited to DoS?, 

Exactly, that's why I have identified it as a "limited" buffer-overflow.
Limited just because the attacker has no control for executing malicious
code, I use this strange term when the return address cannot be
overwritten with the original bytes sent by the attacker.
While I think that the buffer-overflow term is necessary because it's
just what happens, although snprintf handles the attacker's input
correctly.
Anyway if someone has ideas for better and more exact terms I'm open to
suggestions.

> How could one control the result of the FormatMessage for any of those
> two purpouses?

As far as I know the attacker has no ways for changing or modifying the
error message because it's handled by the operating system through
GetLastError (retrieves the system error number) and FormatMessage
(creates a text message for that specific system error).

Oh last note, I have updated my advisory for this second bug [B] adding
an important detail about the exploitation which I forgot yesterday:

The only way I have found for exploiting this bug (moreover without
authentication) is through the sending of a HTTP request with an URI of
about 1024 bytes to the built-in webserver used for allowing the
clients to download the Java viewer.
The service runs on port 5800 and is enabled by default.

BYEZ

--- 
Luigi Auriemma
http://aluigi.altervista.org