SecurityReason.com - Our Reason is

Security

Register | Forget Password | Login
SecurityReason
IT News
Search
SecurityAlert Database
About SecurityAlert
ExploitAlert Database
SecurityReason Research
WLB
WLB Database
Send to WLB
About WLB
Services
Security Audit
Schedule
Prices of services
Contact
RSS
SecurityReason IT News
SecurityAlert
World Laboratory of Bugtraq
ExploitAlert
Apache
PHP
Corporate
Contact
About SecurityReason
Note

If you have found a vulnerability, please send to our SecurityAlert Database :
secalert()securityreason()com

Also if you have new ( 0-day ) exploit, please send to our ExploitAlert Archive :
exploit()securityreason()com
Home arrow SecurityAlert Database

Arrow  Topic :

MSIE7 entrapment again (+ FF tidbit)


Arrow  SecurityAlert : 2892
Arrow  CVE : CVE-2007-3827
Arrow  CVE : CVE-2007-3826
Arrow  SecurityRisk : Low  Security Risk Low  (About)
Arrow  Remote Exploit : Yes
Arrow  Local Exploit : Yes
Arrow  Exploit Available : Yes
Arrow  Credit : Michal Zalewski
Arrow  Published : 20.07.2007

Arrow  Affected Software : Microsoft Internet Explorer, FireFox



Arrow  Advisory Content :  

Hello again,

Microsoft Internet Explorer seems to have a soft spot for browser
entrapment vulnerabilities. Just to recap, in these attacks, the user is
made believe he had left a webpage (and the URL bar or SSL state data
reinforce him in this belief) - but in reality, is prevented from doing
so, and his browser continues to display assorted content originating from
the attacker.

This is a close, but somewhat more sinister relative of vanilla URL bar
spoofing. I reported a few of each kind in the recent months.

Well, here's another one, this time based on document.open() calls. In
essence, repeatedly calling this function after a new URL is entered by
the user, before onBeforeUnload is invoked, inhibits page transition - but
target URL bar state is retained. This is remarkably silly.

A live demo is available here:
http://lcamtuf.coredump.cx/ietrap3/

That is all.

...

PS. The promised tidbit - since I'm leaving for a while and won't have
time to research this - in Firefox, javascript: windows can set
'domainless' cookies by specifying 'domain=.' - for example:

open("javascript:document.cookie='foo=bar;domain=.'","_blank");

Fortunately/unfortunately, these cookies do not get sent to all sites - no
session fixation - though can be retrieved by other null-domain
javascript: / data: pages. Specifying other domains won't work. Multiple
periods will be trimmed. Path can be set arbitrarily, with certain
exceptions. Null-domain cookies load properly when stored in cookies.txt.
Q: can this be used in a manner more sinister than merely facilitating
exchange of "markers" between various user-tracking sites?

/mz




Arrow  Feedback :

If you have additional information or notice any errors regarding this security advisory, please use contact form or email us at info()securityreason()com.
Alert

libc/fnmatch(3) DoS

Security Risk Medium- 2011-05-13

Allow attacker to denial of service apache 2.2.17 server
Apache RSS Apache Alert

» Apache HTTP Server Denial
   of Service Vulnerability

» Multiple Vendors
   libc/fnmatch(3) DoS (incl
   apache poc)

» Apache Continuum
   cross-site scripting
   vulnerability

» Apache Tomcat DoS
   Vulnerability
PHP RSS PHP Alert

» PHP Hashtables Denial of
   Service

» PHP 5.3.6 multiple null
   pointer dereference

» PHP 5.3.6 ZipArchive
   invalid use glob(3)

» libzip 0.9.3
   _zip_name_locate NULL
   Pointer Dereference (incl
   PHP 5.3.5)
ADT

Protect your family and valuables with Home Security Systems
Copyright © SecurityReason.com. All Rights Reserved.