[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer-overflow in Ultr@VNC 1.0.1 viewer and server
> 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
Anyway if someone has ideas for better and more exact terms I'm open to
> 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.