Re: Buffer-overflow in Ultr@VNC 1.0.1 viewer and server
jalvare7@xxxxxxxxxxx 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