lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <00c101ca0f0f$0c4cdb50$010000c0@ml>
Date: Tue, 28 Jul 2009 02:07:03 +0300
From: "MustLive" <mustlive@...security.com.ua>
To: <advisories@...ern0t.net>
Cc: <bugtraq@...urityfocus.com>
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and  Chrome

Hello MaXe!

> I agree completely with mz,

I already wrote an answer on Michal letter, which you could read at Bugtraq
(http://www.securityfocus.com/archive/1/505251/30/0/threaded). There I made
enough arguments why it's dangerous vulnerability and why Mozilla and
Michal are not right and so it's better to fix it. Read my message at
Bugtraq, maybe it'll change your mind on this issue ;-).

> The best way to defend against any Cross Site Scripting attacks is to
> sanitize all inputs and outputs properly on your website

XSS vulnerabilities must be fixed and when they are made at web sites, then
they must be fixed at web sites. But in this case browsers developers made
XSS holes (JavaScript execution) in redirectors, so they just from
Redirector vulnerability (which can be used for redirection to malicious
sites and some other attacks) also become XSS (JavaScript execution)
vulnerability. And there are a lot of redirectors (open ones) in Internet,
as refresh-header redirectors, as location-header redirectors. So these XSS
holes better to fix in browsers, because web developers will be fixing them
for long, like they are fixing their Redirector holes.

In my upcoming article about JavaScript execution attacks in different
browsers via different redirectors I'll write in detail about this attack
vector. I'll made my article on Ukrainian and English.

> If it was possible to execute system() commands directly through the
> browser

It's possible to use this vulnerability for phishing and for spreading
malware. And after it'll be run at user's computer, malware can run system
commands :-). So attacks will be doing directly through the browser.

Best wishes & regards,
MustLive
Administrator of Websecurity web site
http://websecurity.com.ua

----- Original Message ----- 
From: <advisories@...ern0t.net>
To: <mustlive@...security.com.ua>; <lcamtuf@...edump.cx>
Cc: <bugtraq@...urityfocus.com>
Sent: Thursday, July 16, 2009 9:18 AM
Subject: Re: Cross-Site Scripting vulnerability in Mozilla, Firefox and
Chrome


>I agree completely with mz,
>
>
> This is just how FireFox works, the
> data:text/html,base64;somestringinbase64== is just pure functionality. The
> redirection parameters is not equal to a vulnerability since as mz said,
> the attacker could just redirect to his own site.
>
> The best way to defend against any Cross Site Scripting attacks is to
> sanitize all inputs and outputs properly on your website and perhaps run
> NoScript as an extra safety precaution as well.
>
> If it was possible to execute system() commands directly through the
> browser and not javascript nor html then that would be a vulnerability
> since One could almost do anything with a malicious site, if the input in
> this example to this function wouldn't be sanitized of course.
>
>
> Best Regards,
> MaXe
>
>> To bypass protection from JavaScript code execution via refresh header
>> it's
>> needed to use data: URI, which will be containing requisite JS code.
>> [...] After I informed Mozilla, they declined to fix this vulnerability.
>
> "Refresh" or "Location" redirection in Firefox will not bestow a
> security context derived from the referring site upon the executed
> code. This is different from the behavior on javascript: URLs.
> Granted, it and also somewhat counterintuitive, as other types of
> data: navigation - e.g., link navigation, IFRAMEd content, location.*
> updates - do inherit that context.
>
> This means that there is nothing to be gained by redirecting to data:
> through www.example.com; he could as well just redirect to his own
> site and run any potentially malicious JavaScript there.
>
> /mz 


!DSPAM:4a6e333846404117314935!


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ