-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

 ===========-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-===========
   VizibleSoft Security Advisory #2004/01                       25th Mar 2004

   http://viziblesoft.com/insect/advisories/vz012004-esignal7.txt
   insect@viziblesoft.com
 ===========-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-===========

   Product:     eSignal 7.6, 7.5 (maybe earlier)
                http://www.esignal.com

   Systems:     Windows (all versions)

   Problem:     Stack-based buffer overflow

   Severity:    Remote code execution

   Risk:        High
 -----------------------------------------------------------------------------

   Product description:
   ~~~~~~~~~~~~~~~~~~~~
   "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..."


   Vulnerability:
   ~~~~~~~~~~~~~~
   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
   <STREAMQUOTE>
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA....... x 1040
   </STREAMQUOTE>

    ... bang!

   Overflow occurs in Specs.dll and EIP is fully controllable, as
   the function return address on the stack is completelly overwritten.


   Exploitation:
   ~~~~~~~~~~~~~
   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:

   http://viziblesoft.com/insect/sploits/vz-eSignal76.pl


   Solution:
   ~~~~~~~~~
   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
   any answer.

   Thus, solution is obvious:

   Close tcp 80 to outside world with your favorite firewall.


   Disclaimer:
   ~~~~~~~~~~~
   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.

   Legal Notice:
   ~~~~~~~~~~~~~
   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".

   <!huh>

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQIVAwUAQGMb+f/UvuCUTXKfAQERWRAAhj4gp6QOExt2ofKdLWQKdRd/6EHOi8FI
2XLh1EoasSOcaFJh3fB0/L2dZaEKEGTMRuZYPwYguu/BbTGSniCh7nkr5V2hzYZA
a41d6D3vfRQr8kAK+JyDLF0SAsaUHm+AavCKVZKtC/BmDnUvlNJcLXLOMSeFew9R
MkzukqSKhdGww8CkNm++Klp/qL9wArOUQTaUEbLX4IndifEb19ZdGIst/OeXMNzw
s7Bgn6QEcdHroTjOrndS1t3wIyjFR2BeYDVDdGZxksgk9iIqTq4j9IY147NYJ4q3
3ya9Rk9xRlbydpcOFr8t1Ah7B6N3/2lrHFQ3Kv5N3y7n47lAiJiYIqs/Dv88lD8a
G7hZDTULjROJyE+KpU3FE2tvFquasIOPOvhnoIZOs1nMXyGe4zJojkd4qB+zHPjo
ztj+hqBHRY1PkJhgtsKvfIZJMOTCdD9DYk2ouJnAIugevfSbnJcw0S5lyKgmUT/q
KzEgWbOFmHzIuI4JtgjsL2cQxyDIz9NV5nxcTtmX6EqixrPYzGCKoA2biv1aaLLH
PuwKbJNVI7sfzx9dCJddeTiYkd0nsw9uJd/G/QTh18iD6U/9V0ueD/HCc6pdL+kL
j7wh5lNnhi9S0s9d+NNyigKkNk2TblRxXSfdmOajojJAMr9lTm35P4gYcteT7f35
5IvVUQKTeHo=
=kVJa
-----END PGP SIGNATURE-----