Buffer-overflow in Ultr@VNC 1.0.1 viewer and server

2006.04.05
Risk: High
Local: Yes
Remote: Yes
CWE: CWE-119


CVSS Base Score: 9/10
Impact Subscore: 10/10
Exploitability Subscore: 8/10
Exploit range: Remote
Attack complexity: Low
Authentication: Single time
Confidentiality impact: Complete
Integrity impact: Complete
Availability impact: Complete

####################################################################### Luigi Auriemma Application: Ultr@VNC http://www.ultravnc.com http://ultravnc.sourceforge.net Versions: <= 1.0.1 (and current CVS) (tabbed_viewer 1.29 is ever the same VNC viewer 1.0.1 and so it's vulnerable too) Platforms: Windows Bugs: A] client Log::ReallyPrint buffer-overflow B] server VNCLog::ReallyPrint limited buffer-overflow Exploitation: A] remoto, versus client B] remoto, versus server Date: 04 Apr 2006 Author: Luigi Auriemma e-mail: aluigi (at) autistici (dot) org [email concealed] web: http://aluigi.altervista.org ####################################################################### 1) Introduction 2) Bugs 3) The Code 4) Fix ####################################################################### =============== 1) Introduction =============== Ultr@VNC is a well known open source VNC server and viewer for Windows very easy to use and configure. ####################################################################### ======= 2) Bugs ======= ------------------------------------------ A] client Log::ReallyPrint buffer-overflow ------------------------------------------ During the login process a VNC client can receive three types of replies from the server: connection failed, no authentication and authentication required. The first type of reply (rfbConnFailed) is followed by a text string containing the reason of the disconnection. Before visualizing this message Ultr@VNC logs everything in the log file using the vnclog.Print function which adopts a buffer of 1024 bytes (LINE_BUFFER_SIZE) for storing the text. The result is that a malicious VNC server could be able to execute malicious code versus a vulnerable Ultr@VNC client which connects to it. From vncviewer/Log.cpp: void Log::ReallyPrint(LPTSTR format, va_list ap) { TCHAR line[LINE_BUFFER_SIZE]; _vstprintf(line, format, ap); if (m_todebug) OutputDebugString(line); if (m_toconsole) { DWORD byteswritten; WriteConsole(GetStdHandle(STD_OUTPUT_HANDLE), line, _tcslen(line)*sizeof(TCHAR), &byteswritten, NULL); }; if (m_tofile && (hlogfile != NULL)) { DWORD byteswritten; WriteFile(hlogfile, line, _tcslen(line)*sizeof(TCHAR), &byteswritten, NULL); } } ----------------------------------------------------- B] server VNCLog::ReallyPrint limited buffer-overflow ----------------------------------------------------- The logging function used by the Ultr@VNC server is affected by a limited buffer-overflow caused by two strcat calls which add a Windows error message to the output buffer. Anyway there is an important detail about the exploitation of this bug. The server is not vulnerable if the admin doesn't touch the "Log debug infos to the WinVNC.log file" flag in the configuration, but when the admin enables this option his server will be vulnerable forever although he will re-disable it. From winvnc/winvnc/vnclog.cpp: void VNCLog::ReallyPrint(const char* format, va_list ap) { time_t current = time(0); if (current != m_lastLogTime) { m_lastLogTime = current; ReallyPrintLine(ctime(&m_lastLogTime)); } // - Write the log message, safely, limiting the output buffer size TCHAR line[LINE_BUFFER_SIZE]; TCHAR szErrorMsg[LINE_BUFFER_SIZE]; DWORD dwErrorCode = GetLastError(); SetLastError(0); FormatMessage( FORMAT_MESSAGE_FROM_SYSTEM, NULL, dwErrorCode, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(char *)&szErrorMsg, LINE_BUFFER_SIZE, NULL); _vsnprintf(line, LINE_BUFFER_SIZE, format, ap); strcat(line," --"); strcat(line,szErrorMsg); ReallyPrintLine(line); } ####################################################################### =========== 3) The Code =========== http://aluigi.altervista.org/poc/uvncbof.zip ####################################################################### ====== 4) Fix ====== A patch will be released in the next weeks. ####################################################################### --- Luigi Auriemma http://aluigi.altervista.org


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top