mailing list archives
eSignal v7 remote buffer overflow (exploit)
From: Vizzy <vizzy () freemail hu>
Date: Thu, 25 Mar 2004 17:53:44 +0000
-----BEGIN PGP SIGNED MESSAGE-----
VizibleSoft Security Advisory #2004/01 25th Mar 2004
insect () viziblesoft com
Product: eSignal 7.6, 7.5 (maybe earlier)
Systems: Windows (all versions)
Problem: Stack-based buffer overflow
Severity: Remote code execution
"eSignal is the nation's leading provider of real-time financial and
market information. eSignal is a popular platform for institutional
and professional traders. eSignal is a market data solution bundled
for best value for small to mid-size institutional investors that
also includes additional optional services..."
eSignal main application "WinSig.exe" listens for incoming data
requests on tcp port 80.
While parsing requests, it suffers from classic stack-based buffer
overflow, when parameter string is about 1040 characters long:
C:\>telnet localhost 80
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA....... x 1040
Overflow occurs in Specs.dll and EIP is fully controllable, as
the function return address on the stack is completelly overwritten.
Pretty trivial, except that overflow string can not contain NULL-bytes
and all lower-case characters are converted to upper-case.
As we overwrite stack with return address and code, we use standard
"JMP ESP" technique to direct execution back to us.
"jmp esp" opcode was found in MFC71.dll, which is distributed in eSignal
package and loads from program folder, thus making exploit to be eSignal
version specific instead of OS (Windoze) specific.
While I was working on advisory, eSignal released v7.6 which is
vulnerable as well and even more "overflow-friendly", as previous
was compiled with debug bits for ESP value checking at the end of each
procedure. But in both cases it's almost similar.
Proof of concept code:
Exploit written in Perl, which downloads and executes file from
the specified URL available here:
Vendor's technical support ignored my request for company's security
contacts. I wasn't surprised, as the most support staff these days is
zombified and can't figure out doing something they were not programmed
to. Plus, company falls into category of "those who does not care"
moneymakers, so after two weeks time I realized there won't be
Thus, solution is obvious:
Close tcp 80 to outside world with your favorite firewall.
The information in this advisory is believed to be true though
it may be false. Use of this information constitutes acceptance for use
in an AS IS condition. There are NO warranties with regard to this
information. In no event shall the authors be liable for any damages
whatsoever arising out of or in connection with the use or spread of this
information. Any use of this information is at the user's own risk.
This advisory is copyright (c) 2004 VizibleSoft.com
You may distribute it unmodified. You may not modify it and distribute
it or distribute parts of it without the author's written permission -
this especially applies to the so called "vulnerabilities databases"
and "security checkers".
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.
- eSignal v7 remote buffer overflow (exploit) Vizzy (Mar 25)