Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: VHCS Security Patch - 2006-02-05 --> Fake!
From: Roman Medina-Heigl Hernandez <roman () rs-labs com>
Date: Tue, 07 Feb 2006 17:30:18 +0100


Let's summary:
1.- You (as VHCS "vendor") publish a patch that when installed opens a
big security hole (as demonstrated in my former analysis).
2.- You didn't notify security mailing-lists (as a responsible vendor
would do if a new security bug has been identified and fixed, which is
what you are claiming).
3.- Someone (me), publicly reports it (with cc to you) (I already argued
why I decided to go public; read my former mail).
4.- You answer saying it has now been fixed but you didn't publish any
reference or info in the VHCS page.
5.- So a VHCS customer who downloaded the wrong patch (and does not
consult security mls/sites) won't notice any change in your original
announce and will be vulnerable indeed. You are not correctly informing
your users.
6.- I publicly ask you for a clarification about the real bug which was
supposed to have been fixed and you didn't answer. Anything to hide?
7.- I didn't get any response but an offending mail accusing me of
elevating alarm level at securitywizardry... Pathetic.

Sorry, but I don't believe in security through obscurity. Insulting
people reporting problems is not the solution. Acknowledging your own
errors and clarifying the situation is. VHCS users deserve an official
explanation. Is / isn't really vulnerable to a new bug?

PS: I'm posting this to full-disclosure, as an example of how a vendor
response to a security issue should never be.

-Román (aka the "stupid asshole" :-))

Alexander Kotov [moleSoftware] wrote:
If you want to go public in the furute fiest conatact someone of the dev
Wait at least 1 day and then go public ...  stupid asshole

here the results of your activiy

Fuck you

Roman Medina-Heigl Hernandez wrote:

Hi Alex,

My apologies if I've been a bit rough, but public security mailing-lists
are intended to deal with (un)security issues. I don't understand why
you didn't announce in mls the issue if a new vuln was being fixed. It
seemed some kind of joke or hack, since I missed the "die()" function
and I only saw security fixes being removed, so it was suspicious. I
decided to go public because people could be downloading wrong patch.

I didn't have time to analyze the effects of die() line there. I suppose
that's the real fix, isn't it? Could you elaborate on that? What's the
real vuln being fixed?

Sorry for the inconvenience. No offense was intended.


Alexander Kotov [moleSoftware] wrote:

Hi Roman,

uffff ... I'm human being and make mistakes. I just got older version of
the file.
Now I rebuilded the tarball and the problem is fixed.

I think it is not necessary to post such kind of messages in public
before you contact someone of the development team and wait at least
some hours.


Roman Medina-Heigl Hernandez wrote:



I've just visited VHCS main page and noticed the following "security


It reads:

"This patch is for all VHCS versions.
You have to update only one GUI file - /vhcs2/gui/include/login.php

Just replace the file

Well, just do NOT apply it!!!! It's a fake! Indeed it will leave your
VHCS installation vulnerable to a high severity cross-site-scripting

See it:
login_orig_unix.php --> original login.php (converted to Unix)
login_new_unix.php  --> login.php from "security patch"

roman () rs-labs:~$ diff login_orig_unix.php login_new_unix.php
<               write_log("Login error,
ENT_QUOTES, "UTF-8")."</i></b> unknown username");


            write_log("Login error, <b><i>".$uname."</i></b> unknown

write_log( htmlspecialchars($uname, ENT_QUOTES, "UTF-8")." Domain
is not OK - user can not login");

write_log( $uname." Domain status is not OK - user can not login");
<                       write_log( htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." user logged in.");


                    write_log( $uname." user logged in.");

<               write_log( htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." bad password login data.");


            write_log( $uname." bad password login data.");

<                       write_log(htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." user session timed out");


                    write_log($uname." user session timed out");

<               write_log(htmlspecialchars($uname, ENT_QUOTES,
"UTF-8")." bad session data.");


            write_log($uname." bad session data.");







< }



roman () rs-labs:~$

As you can see, the "patch" removes htmlspecialchars() calls letting
login.php vulnerable . Nasty...

If you apply the "patch" (or have an old VHCS install, for instance
version <=, the XSS bug is active. Just for fun, you can
exploit it by entering the following as "username" (in the login entry

</form><form name="dsr" method="post"
name="pass" value="hackme"><input name="pass_rep" value="hackme"><input

When the VHCS admin enters the "Admin Log" page (in VHCS menu)... his
password will be set up to "hackme" :-) The %61 trick is necessary to
bypass some string substitution. This exploit combines the XSS bug with
what I see as a poor security design bug, which is letting change
password without supplying the old one (Alex, please, fix it in next

Summarizing, my recommendation: use VHCS, don't apply patch.




Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]