Re: [Full-disclosure] IE UXSS (Universal XSS in IE, was Re: Microsoft Internet Information Services UTF-7 XSS Vulnerability [MS06-053])
I've been testing around a bit with IE 6 and Apache
and I have found that IE behaves a bit strangely...
If the webserver sets the charset in the response, IE
will not interpret the malicious string as being UTF-7
encoded, regardless of the 'auto-select' option in IE.
However, if I enable 'auto-select' *while* viewing the
error page with the malicious string, the XSS works!
For further testing I created a php-script that sets
the "Content-Type" header without setting the charset.
If 'auto-select' is disabled, XSS doesn't work. If
'auto-select' is enabled, XSS does work.
So it seems that, even though the webserver sets the
charset in the response, IE will do its automatic
encoding determination trick anyway, if you enable
'auto-select' while viewing the webpage.
This means that, with a little additional social
engineering, UXSS is possible.
proof of concept:
http://www.apache.srv/+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-/---IF_THIS_PAGE_DOESN'T_DISPLAY_CORRECTLY__ENABLE_'AUTO-SELECT'_IN_THE_VIEW->ENCODING_MENU_OF_YOUR_BROWSER--
;)
--- Paul Szabo <[EMAIL PROTECTED]> wrote:
> Seems that I was wrong and Brian Eaton
> <[EMAIL PROTECTED]> was right:
> default apache installations seem to return an
> explicit charset in their
> error message. (Now I cannot explain how I convinced
> myself otherwise.)
> Then there is no Universal XSS against default
> Apache webservers...
>
> Cheers,
>
> Paul Szabo [EMAIL PROTECTED]
> http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics University of
> SydneyAustralia
>
> ___
> Full-Disclosure - We believe in it.
> Charter:
>
http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia -
> http://secunia.com/
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
I doubt it will work on any windows OS. If a user is logged in as a user who dont have admin rights then unplugging network cable does not give him admin. On 10/3/06, Pink Hat <[EMAIL PROTECTED]> wrote: > This doesn't work on XP. Pulling the network cable *does not* cause the > machine to default to local administrator. From the lame post: > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
On Tue, Oct 03, 2006 at 02:33:34PM +0530, crazy frog crazy frog wrote: > I doubt it will work on any windows OS. If a user is logged in as a > user who dont have admin rights then unplugging network cable does not > give him admin. The hack seems to be the defaulting. You authentify as a user, but you do not let the system to get the full user profile from its domain controller. The bug suggested there is that, if the OS can authentify, but cannot setup the profile after succesfully authentifying, it would incorrectly place you as a local admin. Presumably because that's the only local account. I do suspect a combo of specific OS version, SP, AD/system config, and probably the account setup script that gets executed when you create a local version of the user environment, rather than a generalized system error. Most system will indeed keep a cached copy of the network profile, and default to it when unable to fetch the profile - I'm sure the sysadmins added fancy tricks to destroy any local profile once you've logged out, and the building of the account profile when you log in for "the first time" is where the drop to admin happens. -- Vincent ARCHER [EMAIL PROTECTED] Tel : +33 (0)1 40 07 47 14 Fax : +33 (0)1 40 07 47 27 Deny All - 23, rue Notre Dame des Victoires - 75002 Paris - France ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
List members: please pardon the vocab lesson I'm about to give... it's just a pet peeve of mine. (However, if you're one of those that also butchers this word, please take note.) > The hack seems to be the defaulting. You authentify as a user, but you > do not let the system to get the full user profile from its domain > controller. The bug suggested there is that, if the OS can authentify, > but cannot setup the profile after succesfully authentifying, it would > incorrectly place you as a local admin. Presumably because that's the > only local account. Vincent, please note: http://www.google.com/search?q=define%3Aauthentify returns no results. Yet: http://www.google.com/search?q=define%3Aauthenticate returns 12+. "authentify" is not a word (in English at least). thanks, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
Salut, On Tue, 2006-10-03 at 14:33 +0530, crazy frog crazy frog wrote: > I doubt it will work on any windows OS. If a user is logged in as a > user who dont have admin rights then unplugging network cable does not > give him admin. AFAICT this is not about gaining admin rights (which one would if the machine is a non-NT based Windows) but rather about gaining the right to surf whatever website one wants. This can indeed be achieved by not loading the group policies. (If I'm not mistaken here. I'm a BSD kernel hacker, not a Windows supporter...) Tonnerre -- SyGroup GmbH Tonnerre Lombard Loesungen mit System Tel:+41 61 333 80 33Roeschenzerstrasse 9 Fax:+41 61 383 14 674153 Reinach BL Web:www.sygroup.ch [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
> Vincent, please note: > > http://www.google.com/search?q=define%3Aauthentify > > returns no results. Yet: > > http://www.google.com/search?q=define%3Aauthenticate > > returns 12+. > > "authentify" is not a word (in English at least). Hello list, and sorry for the noise. Vincent wrote me privately and noted that: "authentifier" is the right french word for authenticate. Which is the reason he was a bit confused. Sorry if I came across as a stereotypical ethnocentric American. cheers, tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
Two things. How is the user able to get the internet while the network cable is unplugged? Secondly, it is the proxy server in 99% of cases which restricts which websites the user can/cannot visit, not the local policies. This whole subject of pulling out the network cable giving admin is gay. Have a lovely day. c0redump aka Tom >Salut, >On Tue, 2006-10-03 at 14:33 +0530, crazy frog crazy frog wrote:> I doubt it will work on any windows OS. If a user is logged in as a> user who dont have admin rights then unplugging network cable does not> give him admin. >AFAICT this is not about gaining admin rights (which one would if the>machine is a non-NT based Windows) but rather about gaining the right to>surf whatever website one wants. This can indeed be achieved by not>loading the group policies. (If I'm not mistaken here. I'm a BSD kernel>hacker, not a Windows supporter...) >Tonnerre>-- >SyGroup GmbH>Tonnerre Lombard >Loesungen mit System>Tel:+41 61 333 80 33 Roeschenzerstrasse 9>Fax:+41 61 383 14 67 4153 Reinach BL>Web:www.sygroup.ch [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
On Mon, 25 Sep 2006 14:16:07 BST, [EMAIL PROTECTED] said: > How is the user able to get the internet while the network cable is unplugged? Well, assuming the hack actually *works*, once you're logged on as a local admin, you're free to plug the cable back in. (If the *real* issue here is that your profile isn't available, it might get interesting if it happens to show up once you're logged in. But I seem to remember that GPO is only applied at logon, because you have to bounce active users to push a new one. I'm not a windows guy so I may be wrong thought...) > Secondly, it is the proxy server in 99% of cases which restricts which > websites the user can/cannot visit, not the local policies. One might hope that. But there's an awful lot of McSE (you want fries with that) out there that: a) Don't know how to set up a proxy server, but do know how to set a local policy. b) Don't understand the difference between "default deny" and "default allow", and why one leads to whack-a-mole website hunting pgpynWFxtkSW1.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] iDefense Security Advisory 10.02.06: Novell GroupWise Messenger nmma.exe DoS Vulnerability
Novell GroupWise Messenger nmma.exe DoS Vulnerability iDefense Security Advisory 10.02.06 http://www.idefense.com/intelligence/vulnerabilities/ Oct 02, 2006 I. BACKGROUND Novell Messenger is a corporate, cross-platform instant messaging product that is based on Novell eDirectory. More information is available at the following site: http://www.novell.com/documentation/nm2/ II. DESCRIPTION Remote exploitation of a DoS vulnerability in Novell Inc.'s GroupWise Messenger could allow attackers to crash the Messenger server. The vulnerability specifically exists due to improper handling of a an HTTP POST request with a modified 'val' paramater. When such a request is received, a NULL pointer dereference occurs, leading to a crash of the service. III. ANALYSIS Successful exploitation of this vulnerability would result in the server crashing, rendering it unusable until it is restarted. Further exploitation does not appear possible. In order to exploit this vulnerability, an attacker must send a specially constructed HTTP request to the server on TCP port 8300. IV. DETECTION iDefense has confirmed this vulnerability in Novell GroupWise Messenger version 2. All previous versions are suspected vulnerable. V. WORKAROUND iDefense is currently unaware of any effective workarounds for this issue. VI. VENDOR RESPONSE Novell has released updates in the form of Hot Patches. More information on the security update can be found via the following link. http://support.novell.com/filefinder/security/index.html VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2006-4511 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 08/17/2006 Initial vendor notification 08/18/2006 Initial vendor response 10/02/2006 Coordinated public disclosure IX. CREDIT CIRT.DK is credited with the discovery of this vulnerability. Get paid for vulnerability research http://www.idefense.com/methodology/vulnerability/vcp.php Free tools, research and upcoming events http://labs.idefense.com/ X. LEGAL NOTICES Copyright © 2006 iDefense, Inc. Permission is granted for the redistribution of this alert electronically. It may not be edited in any way without the express written consent of iDefense. If you wish to reprint the whole or any part of this alert in any other medium other than electronically, please email [EMAIL PROTECTED] for permission. Disclaimer: The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Security Rss Feeds
Another one to add is http://www.computerdefense.org/?feed=rss2Tyler.On 9/30/06, crazy frog crazy frog <[EMAIL PROTECTED]> wrote: Hi,Please share various security related rss feeds you read daily.Thanks,-CF___Full-Disclosure - We believe in it.Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
Wrong. It is about getting local admin rights in this case as the so called attack scenario requires it. List -- this is so easy to disprove yet we have all kinds of so called security professonals and in this case a (wow, I am almost pissing myself) BSD Kernel hacker, stating that they feel its a possible attack. Go grab VMWare and various windows versions from your favorite warez site and spend the time to actually try things and understand how the technology works before you comment. The bottom line is that what was posted on that site about "hacking high school computers" is false. On 10/3/06, Tonnerre Lombard <[EMAIL PROTECTED]> wrote: Salut,On Tue, 2006-10-03 at 14:33 +0530, crazy frog crazy frog wrote:> I doubt it will work on any windows OS. If a user is logged in as a > user who dont have admin rights then unplugging network cable does not> give him admin.AFAICT this is not about gaining admin rights (which one would if themachine is a non-NT based Windows) but rather about gaining the right to surf whatever website one wants. This can indeed be achieved by notloading the group policies. (If I'm not mistaken here. I'm a BSD kernelhacker, not a Windows supporter...) Tonnerre --SyGroup GmbHTonnerre LombardLoesungen mit SystemTel:+41 61 333 80 33Roeschenzerstrasse 9Fax:+41 61 383 14 674153 Reinach BLWeb:www.sygroup.ch [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Removing the NIC cable = EoP?
Who gives a flying fuck about what words he uses. Are you really that out of your league on this list that you need to concentrate on the words/gramar/etc of others. He got his point across so who cares. On 10/3/06, Tim <[EMAIL PROTECTED]> wrote: > Vincent, please note:>> http://www.google.com/search?q=define%3Aauthentify>> returns no results. Yet:>> http://www.google.com/search?q=define%3Aauthenticate >> returns 12+.>> "authentify" is not a word (in English at least).Hello list, and sorry for the noise. Vincent wrote me privately andnoted that:"authentifier" is the right french word for authenticate. Which is the reason he was a bit confused. Sorry if I came across as astereotypical ethnocentric American.cheers,tim___Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.htmlHosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Registration Weakness in L inux Kernel's Binary formats
Hello, The present document aims to demonstrate a design weakness found in the handling of simply linked lists used to register binary formats handled by Linux kernel, and affects all the kernel families (2.0/2.2/2.4/2.6), allowing the insertion of infection modules in kernel space that can be used by malicious users to create infection tools, for example rootkits. POC, details and proposed solution at: English version: http://www.shellcode.com.ar/docz/binfmt-en.pdf Spanish version: http://www.shellcode.com.ar/docz/binfmt-es.pdf regards, -- SHELLCODE Security Research TEAM [EMAIL PROTECTED] http://www.shellcode.com.ar ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [CAID 34661]: CA Unicenter WSDM File System Read Access Vulnerability
Title: CAID 34661: CA Unicenter WSDM File System Read Access Vulnerability CA Vulnerability ID (CAID): 34661 CA Advisory Date: 2006-10-03 Discovered By: Oliver Karow, Symantec Security Consultant oliver_karow at symantec dot com Richard Sammet, Symantec Security Consultant richard_sammet at symantec dot com Impact: Remote attacker can access sensitive information. Summary: Unicenter Web Services Distributed Management 3.1 uses a known vulnerable version of Jetty WebServer, an open source java web server. An advisory describing the Jetty WebServer vulnerability can be found at http://www.securityfocus.com/bid/11330. The vulnerability allows a remote attacker to gain full read access on the install partitions file system of the Unicenter WSDM host system through a directory traversal attack [e.g. http://192.168.50.31:8282/..\..\..\..\boot.ini]. Mitigating Factors: This is an older vulnerability that was addressed in December 2004 with the release of Unicenter Web Services Distributed Management (WSDM) 3.11. Severity: CA has given this vulnerability a Medium risk rating. Affected Products: CA Unicenter Web Services Distributed Management (WSDM) 3.1 Affected platforms: Red Hat Linux Solaris SUSE Linux Microsoft Windows Status and Recommendation: This vulnerability was addressed in December 2004 with the release of Unicenter Web Services Distributed Management (WSDM) 3.11. Customers using Unicenter WSDM 3.1 should upgrade to WSDM 3.11 or later through the CA SupportConnect web site at http://supportconnect.ca.com. Determining if you are affected: The WSDM version in use can be determined by viewing the downloaded package name. Search for files named CAWSDM_3_1.xxx. References (URLs may wrap): CA SupportConnect: http://supportconnect.ca.com/ CA SupportConnect Security Notice for this vulnerability: Important Security Notice for CA Unicenter WSDM (File System Read Access Vulnerability) http://supportconnectw.ca.com/public/ca_common_docs/wsdmvuln_notice.asp CAID: 34661 CAID Advisory link: http://www3.ca.com/securityadvisor/vulninfo/vuln.aspx?id=34661 Discoverer: Symantec http://www.symantec.com CVE Reference: CVE-2004-2478 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2478 OSVDB Reference: OSVDB ID: 10490 http://osvdb.org/10490 Changelog for this advisory: v1.0 - Initial Release Customers who require additional information should contact CA Technical Support at http://supportconnect.ca.com. For technical questions or comments related to this advisory, please send email to [EMAIL PROTECTED], or contact me directly. If you discover a vulnerability in CA products, please report your findings to [EMAIL PROTECTED], or utilize our "Submit a Vulnerability" form. URL: http://www3.ca.com/securityadvisor/vulninfo/submit.aspx Regards, Ken Williams ; 0xE2941985 Director, CA Vulnerability Research CA, One Computer Associates Plaza. Islandia, NY 11749 Contact http://www3.ca.com/contact/ Legal Notice http://www3.ca.com/legal/ Privacy Policy http://www3.ca.com/privacy/ Copyright © 2006 CA. All rights reserved. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Firefox Vulnerabilities FAKED
Nice to see that a group of idiots can turn a conference into a joke just as easily as they can a mailing list. Was there any technical verification from the Toorcon guys before they accepted these asshats talk? http://developer.mozilla.org/devnews/index.php/2006/10/02/update-possible-vulnerability-reported-at-toorcon The main purpose of our talk was to be humorous. As part of our talk we mentioned that there was a previously known Firefox vulnerability that could result in a stack overflow ending up in remote code execution. However, the code we presented did not in fact do this, and I personally have not gotten it to result in code execution, nor do I know of anyone who has. I have not succeeded in making this code do anything more than cause a crash and eat up system resources, and I certainly haven't used it to take over anyone else's computer and execute arbitrary code. I do not have 30 undisclosed Firefox vulnerabilities, nor did I ever make this claim. I have no undisclosed Firefox vulnerabilities. The person who was speaking with me made this claim, and I honestly have no idea if he has them or not. I apologize to everyone involved, and I hope I have made everything as clear as possible. Sincerely, Mischa Spiegelmock ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
Media whores. - Original Message - From: Pink Hat To: full-disclosure@lists.grok.org.uk Sent: Tuesday, October 03, 2006 9:12 PM Subject: [Full-disclosure] Firefox Vulnerabilities FAKED Nice to see that a group of idiots can turn a conference into a joke just as easily as they can a mailing list. Was there any technical verification from the Toorcon guys before they accepted these asshats talk? http://developer.mozilla.org/devnews/index.php/2006/10/02/update-possible-vulnerability-reported-at-toorcon The main purpose of our talk was to be humorous. As part of our talk we mentioned that there was a previously known Firefox vulnerability that could result in a stack overflow ending up in remote code execution. However, the code we presented did not in fact do this, and I personally have not gotten it to result in code execution, nor do I know of anyone who has. I have not succeeded in making this code do anything more than cause a crash and eat up system resources, and I certainly haven't used it to take over anyone else's computer and execute arbitrary code. I do not have 30 undisclosed Firefox vulnerabilities, nor did I ever make this claim. I have no undisclosed Firefox vulnerabilities. The person who was speaking with me made this claim, and I honestly have no idea if he has them or not. I apologize to everyone involved, and I hope I have made everything as clear as possible. Sincerely, Mischa Spiegelmock ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] [Full-dislcosure] ZERT patch for setSlice()
So how is this a patch when you are simply automating a simple work around? If this can be called a patch then we should be able to say that Microsoft released a patch in their bulletin on this issue where they describe exactly how to set the killbit. A *real* patch would actually address the vulnerable code. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Advisory 08/2006: PHP open_basedir Race Condition Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hardened-PHP Project
www.hardened-php.net
-= Security Advisory =-
Advisory: PHP open_basedir Race Condition Vulnerability
Release Date: 2006/10/04
Last Modified: 2006/10/04
Author: Stefan Esser [EMAIL PROTECTED]
Application: PHP 4/5
Not affected: PHP with Suhosin Extension 0.9.6
Severity: A design flaw of open_basedir allows bypassing it
with the symlink() function
Risk: Critical
References: http://www.hardened-php.net/advisory_082006.132.html
Overview:
Quote from http://www.php.net
"PHP is a widely-used general-purpose scripting language that
is especially suited for Web development and can be embedded
into HTML."
The design of the open_basedir feature of PHP that is meant to
disallow access to files outside a set of configured directories
is vulnerable to race conditions.
It was discovered that this design flaw can be exploited with
the usage of PHP's symlink() function in a very easy way.
We believe that the only solution to this problem is disabling
the function symlink() while open_basedir is used (this feature
was therefore added to our Suhosin PHP Security Extension).
Fixing the flaw in the open_basedir design seems infeasible
because there is no way to fix the potential race condition
when accessing the file is done within an external library.
The successful exploitation of this vulnerability allows access
to files normally not accessible due to the open_basedir
restriction.
Details:
PHP's open_basedir feature is meant to disallow scripts to access
files outside a set of configured base directories. The checks
for this are placed within PHP functions dealing with files before
the actual open call is performed.
Obviously there is a little span of time between the check and the
actual open call. During this time span the checked path could
have been altered and point to a file that is forbidden to be
accessed due to open_basedir restrictions.
Because the open_basedir restrictions often not call PHP functions
but 3rd party library functions to actually open the file it is
impossible to close this time span in a general way. It would only
be possible to close it when PHP handles the actual opening on it's
own.
While it seems hard to change the path during this little time span
it is very simple with the use of the symlink() function combined
with a little trick. PHP's symlink() function ensures that source
and target of the symlink operation are allowed by open_basedir
restrictions (and safe_mode). However it is possible to point a
symlink to any file by the use of mkdir(), unlink() and at least
two symlinks.
Example (pseudo PHP code):
mkdir("a/a/a/a/a/a");
symlink("a/a/a/a/a/a", "dummy");
symlink("dummy/../../../../../../", "xxx");
unlink("dummy");
symlink(".", "dummy");
After this code sequence "xxx" points to 6 directories up. Having
achieved this it is possible for an attacker to exploit the race
condition by creating 2 PHP scripts.
The first script alternates a symbolic link between a file that
is allowed and the one that is forbidden by open_basedir and the
second script simply puts loops around operations trying to
operate on the symbolic link.
The result is that sometimes in the loop the race is lost and the
operation is performed on the allowed file, sometimes it just
produces errors, because the symlink was deleted and sometimes it
triggers the open_basedir error-message. However sooner or later
the race will be won and the operation is performed on the file
that is actually forbidden due to open_basedir restrictions.
Proof of Concept:
The Hardened-PHP Project is not going to release exploits for
this vulnerability to the public.
Disclosure Timeline:
02. October 2006 - Notified [EMAIL PROTECTED]
04. October 2006 - Public Disclosure
Recommendation:
Because the design flaw cannot be solved it is strongly recommended
to disable the symlink() function if you are using the open_basedir
feature. You can achieve that by adding symlink to the list of
disabled functions within your php.ini
disable_functions=...,symlink
Additionally you should start thinking about not relying on PHP's
open_basedir and safe_mode restrictions but on actual operating
system features like chroots and jails, because open_basedir and
safe_mode are simply insecure by design.
As usual we also strongly recommend to install the latest version
of our Suhosin Extension. The current version 0.9.6 disallows
symlink() while open_basedir is used by default. Additionally it
comes with configurable function black- and white-lists that
can work (unlike disable_func
[Full-disclosure] [ MDKSA-2006:179 ] - Updated openssh packages fix DoS vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ___ Mandriva Linux Security Advisory MDKSA-2006:179 http://www.mandriva.com/security/ ___ Package : openssh Date: October 3, 2006 Affected: 2006.0, 2007.0, Corporate 3.0, Corporate 4.0, Multi Network Firewall 2.0 ___ Problem Description: Tavis Ormandy of the Google Security Team discovered a Denial of Service vulnerability in the SSH protocol version 1 CRC compensation attack detector. This could allow a remote unauthenticated attacker to trigger excessive CPU utilization by sending a specially crafted SSH message, which would then deny ssh services to other users or processes (CVE-2006-4924, CVE-2006-4925). Please note that Mandriva ships with only SSH protocol version 2 enabled by default. Next, an unsafe signal handler was found by Mark Dowd. This signal handler was vulnerable to a race condition that could be exploited to perform a pre-authentication DoS, and theoretically a pre-authentication remote code execution in the case where some authentication methods like GSSAPI are enabled (CVE-2006-5051). Updated packages have been patched to correct this issue. ___ References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4924 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4925 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5051 ___ Updated Packages: Mandriva Linux 2006.0: 1280b30b3520a9ca5c2e6a716a770a0c 2006.0/i586/openssh-4.3p1-0.3.20060mdk.i586.rpm 007b28a957c4537d6ed196d2b2367c1e 2006.0/i586/openssh-askpass-4.3p1-0.3.20060mdk.i586.rpm 280b2c0b27ef2387110d363493be892f 2006.0/i586/openssh-askpass-gnome-4.3p1-0.3.20060mdk.i586.rpm 3a41abc407c20928f672223c67d06c36 2006.0/i586/openssh-clients-4.3p1-0.3.20060mdk.i586.rpm 063589a511985d4127e03c349fa23330 2006.0/i586/openssh-server-4.3p1-0.3.20060mdk.i586.rpm 6f11187f048ef296607c54c1c92e7c24 2006.0/SRPMS/openssh-4.3p1-0.3.20060mdk.src.rpm Mandriva Linux 2006.0/X86_64: 68bc6ad235e0534bc57e180b90c33bdb 2006.0/x86_64/openssh-4.3p1-0.3.20060mdk.x86_64.rpm d0668a2d76eb927afcaa4897fc509f91 2006.0/x86_64/openssh-askpass-4.3p1-0.3.20060mdk.x86_64.rpm 502b3088f7f55d3de57b2278b5452a5a 2006.0/x86_64/openssh-askpass-gnome-4.3p1-0.3.20060mdk.x86_64.rpm 2551d84521716a9b6702a98b9d121b9d 2006.0/x86_64/openssh-clients-4.3p1-0.3.20060mdk.x86_64.rpm c8627d7e04e87c1e5bed7d0b744b2ad2 2006.0/x86_64/openssh-server-4.3p1-0.3.20060mdk.x86_64.rpm 6f11187f048ef296607c54c1c92e7c24 2006.0/SRPMS/openssh-4.3p1-0.3.20060mdk.src.rpm Mandriva Linux 2007.0: 9687bdb4f2865c2765da0f01efda87ef 2007.0/i586/openssh-4.3p2-12.1mdv2007.0.i586.rpm 40f80b906c0e9ec5d2d6622ce7efc3fd 2007.0/i586/openssh-askpass-4.3p2-12.1mdv2007.0.i586.rpm b50bae14a353fdd3ca632096467a51cd 2007.0/i586/openssh-askpass-common-4.3p2-12.1mdv2007.0.i586.rpm 0d393f5af4f97c0ca2073c3f11628a40 2007.0/i586/openssh-askpass-gnome-4.3p2-12.1mdv2007.0.i586.rpm 084d0fa10aa7daa1aaea59cb2efc9494 2007.0/i586/openssh-clients-4.3p2-12.1mdv2007.0.i586.rpm 07f0a46845c178b78549c0734074407f 2007.0/i586/openssh-server-4.3p2-12.1mdv2007.0.i586.rpm c9ccf40372c7c2b0eca968aec9f9385d 2007.0/SRPMS/openssh-4.3p2-12.1mdv2007.0.src.rpm Mandriva Linux 2007.0/X86_64: a1ed25a9f53038434574b3ce921eac1a 2007.0/x86_64/openssh-4.3p2-12.1mdv2007.0.x86_64.rpm d9acf43a28f105d80fcd7a12535efdda 2007.0/x86_64/openssh-askpass-4.3p2-12.1mdv2007.0.x86_64.rpm ed6488abb9c621dab762307136493969 2007.0/x86_64/openssh-askpass-common-4.3p2-12.1mdv2007.0.x86_64.rpm ef48a28c45ec44dc1f20eb0ee26f4877 2007.0/x86_64/openssh-askpass-gnome-4.3p2-12.1mdv2007.0.x86_64.rpm 80c7ee2ccb6ac35fe1b893cb58b092cd 2007.0/x86_64/openssh-clients-4.3p2-12.1mdv2007.0.x86_64.rpm 217eb2fbf7574aa34a592e54d527f8dd 2007.0/x86_64/openssh-server-4.3p2-12.1mdv2007.0.x86_64.rpm c9ccf40372c7c2b0eca968aec9f9385d 2007.0/SRPMS/openssh-4.3p2-12.1mdv2007.0.src.rpm Corporate 3.0: 08ee3d3de53563481a748d8b4d9f5e5b corporate/3.0/i586/openssh-4.3p1-0.2.C30mdk.i586.rpm bb472724a2e1afce4b2d526f75d65d3e corporate/3.0/i586/openssh-askpass-4.3p1-0.2.C30mdk.i586.rpm cdcf5e37768032e2c6599d219493db0c corporate/3.0/i586/openssh-askpass-gnome-4.3p1-0.2.C30mdk.i586.rpm 1909a018d6883df234a2bb41072a839b corporate/3.0/i586/openssh-clients-4.3p1-0.2.C30mdk.i586.rpm fc516bf57f9faf0168fef9638f1f7546 corporate/3.0/i586/openssh-server-4.3p1-0.2.C30mdk.i586.rpm b6c94995c4c1408a1d72b6fb1956e7c1 corporate/3.0/SRPMS/openssh-4.3p1-0.2.C30mdk.src.rpm Corporate 3.0/X86_64: dab1069ffd0d206b230872ce11d6ef32 corporate/3.0/x86_64/openssh-4.3p1-0.2.C3
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
if [EMAIL PROTECTED] is actually Mischa Spiegelmock i'll eat my two week old tighty whities on youtoube.com and about the claim that it is a fake: The JavaScript issue appears to be a real vulnerability, Window Snyder, Mozilla's security chief, said after watching a video of the presentation Saturday night. "What they are describing might be a variation on an old attack," she said. "We're going to do some investigating." i trust a girl named window more than a guy named pink -JP On 10/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Media whores. > > - Original Message - > From: Pink Hat > To: full-disclosure@lists.grok.org.uk > Sent: Tuesday, October 03, 2006 9:12 PM > Subject: [Full-disclosure] Firefox Vulnerabilities FAKED > > > Nice to see that a group of idiots can turn a conference into a joke > just as easily as they can a mailing list. Was there any technical > verification from the Toorcon guys before they accepted these asshats > talk? > > > http://developer.mozilla.org/devnews/index.php/2006/10/02/update-possible-vulnerability-reported-at-toorcon > > > The main purpose of our talk was to be humorous. > > > > As part of our talk we mentioned that there was a previously known > Firefox vulnerability that could result in a stack overflow ending up > in remote code execution. However, the code we presented did not in > fact do this, and I personally have not gotten it to result in code > execution, nor do I know of anyone who has. > > > > I have not succeeded in making this code do anything more than cause a > crash and eat up system resources, and I certainly haven't used it to > take over anyone else's computer and execute arbitrary code. > > > > I do not have 30 undisclosed Firefox vulnerabilities, nor did I ever > make this claim. I have no undisclosed Firefox vulnerabilities. The > person who was speaking with me made this claim, and I honestly have > no idea if he has them or not. > > I apologize to everyone involved, and I hope I have made everything as > clear as possible. > > Sincerely, > > Mischa Spiegelmock > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
Paste the youtube URL when you're done please. Thanks. - Original Message - From: Pink Hat To: Dude VanWinkle Cc: [EMAIL PROTECTED] ; full-disclosure@lists.grok.org.uk Sent: Wednesday, October 04, 2006 12:16 AM Subject: Re: [Full-disclosure] Firefox Vulnerabilities FAKED Seeing how you obviously can't trust a boy to do a man's job. On 10/3/06, Dude VanWinkle <[EMAIL PROTECTED]> wrote: > i trust a girl named window more than a guy named pink You are a bit behind. The very article you quoted has been updated with this; http://news.com.com/2100-1002_3-6121608.html?part=rss&tag=6121608&subj=news So, are you going to eat those tighty whites with or without sauce? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
Site your source silly man. http://developer.mozilla.org/devnews/index.php/2006/10/02/update-possible-vulnerability-reported-at-toorcon <-- was posted last night. The news and window both misrepresented this after the con. On 10/3/06, Dude VanWinkle <[EMAIL PROTECTED]> wrote: > if [EMAIL PROTECTED] is actually Mischa Spiegelmock i'll eat my two > week old tighty whities on youtoube.com > > and about the claim that it is a fake: > > The JavaScript issue appears to be a real vulnerability, Window Snyder, > Mozilla's security chief, said after watching a video of the > presentation Saturday night. "What they are describing might be a > variation on an old attack," she said. "We're going to do some > investigating." > > i trust a girl named window more than a guy named pink > > -JP > > On 10/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Media whores. > > > > - Original Message - > > From: Pink Hat > > To: full-disclosure@lists.grok.org.uk > > Sent: Tuesday, October 03, 2006 9:12 PM > > Subject: [Full-disclosure] Firefox Vulnerabilities FAKED > > > > > > Nice to see that a group of idiots can turn a conference into a joke > > just as easily as they can a mailing list. Was there any technical > > verification from the Toorcon guys before they accepted these asshats > > talk? > > > > > > http://developer.mozilla.org/devnews/index.php/2006/10/02/update-possible-vulnerability-reported-at-toorcon > > > > > > The main purpose of our talk was to be humorous. > > > > > > > > As part of our talk we mentioned that there was a previously known > > Firefox vulnerability that could result in a stack overflow ending up > > in remote code execution. However, the code we presented did not in > > fact do this, and I personally have not gotten it to result in code > > execution, nor do I know of anyone who has. > > > > > > > > I have not succeeded in making this code do anything more than cause a > > crash and eat up system resources, and I certainly haven't used it to > > take over anyone else's computer and execute arbitrary code. > > > > > > > > I do not have 30 undisclosed Firefox vulnerabilities, nor did I ever > > make this claim. I have no undisclosed Firefox vulnerabilities. The > > person who was speaking with me made this claim, and I honestly have > > no idea if he has them or not. > > > > I apologize to everyone involved, and I hope I have made everything as > > clear as possible. > > > > Sincerely, > > > > Mischa Spiegelmock > > > > ___ > > Full-Disclosure - We believe in it. > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > ___ > > Full-Disclosure - We believe in it. > > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > > Hosted and sponsored by Secunia - http://secunia.com/ > > > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
Furthermore, What is funnier? The fact that these clowns managed to get a worthless talk approved for Toorcon or The fact that Window Snyder didn't know enough to recognize that it was BS before opening her huge foreheaded face to the press. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
Seeing how you obviously can't trust a boy to do a man's job. On 10/3/06, Dude VanWinkle <[EMAIL PROTECTED]> wrote: > i trust a girl named window more than a guy named pink You are a bit behind. The very article you quoted has been updated with this; http://news.com.com/2100-1002_3-6121608.html?part=rss&tag=6121608&subj=news So, are you going to eat those tighty whites with or without sauce? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Firefox Vulnerabilities FAKED
damn, guess i should have read the link, i thought pink was saying he _was_ Mischa Spiegelmock still a bet is a bet, i will have to send the link to fd -JP(who knows when he is beat> On 10/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Paste the youtube URL when you're done please. > > Thanks. > > - Original Message - > From: Pink Hat > To: Dude VanWinkle > Cc: [EMAIL PROTECTED] ; full-disclosure@lists.grok.org.uk > Sent: Wednesday, October 04, 2006 12:16 AM > Subject: Re: [Full-disclosure] Firefox Vulnerabilities FAKED > > > Seeing how you obviously can't trust a boy to do a man's job. > > On 10/3/06, Dude VanWinkle <[EMAIL PROTECTED]> wrote: > > > i trust a girl named window more than a guy named pink > > You are a bit behind. The very article you quoted has been updated with > this; > > http://news.com.com/2100-1002_3-6121608.html?part=rss&tag=6121608&subj=news > > So, are you going to eat those tighty whites with or without sauce? > > > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Truths in "Truth in Caller ID Act"
On Mon, 2 Oct 2006, Nancy Kramer wrote: > You are 100 percent right about the US government. The US Constitution may > protect US citizens from the government but nothing will protect them from > the big telecom companies who will own them and their data unless we enact > a new neutrality law in the US. > > Regards, > > Nancy Kramer Yes. And we know the exact phrasing of the law: require common carriage on fast telecommunications, just as we require it on slow telecommunications. The issue is wiretapping, and interference with private and public communications. oo--JS. > Webmaster http://www.americandreamcars.com > Free Color Picture Ads for Collector Cars > One of the Ten Best Places To Buy or Sell a Collector Car on the Web > > > At 04:48 PM 10/1/2006, Joe Barr wrote: > >> On Sun, 2006-10-01 at 12:28 -0500, J. Oquendo wrote: >>> So the United States government wants to pass the "Truth in Caller ID" >>> act. Humorously it will do little do deter criminals from spoofing >>> their caller ID and scamming innocent victims. Here is the rule/law >>> followed by why it will fail: >> >> The U.S. government will do its duty, that is to say, they will lick the >> ass of the telecommunications industry lobbyists and do whatever they >> damn well say. >> >> >> >> >> >> -- >> It's a strange world when proprietary software is not worth stealing, >> but free software is. >> >> >> ___ >> Full-Disclosure - We believe in it. >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html >> Hosted and sponsored by Secunia - http://secunia.com/ >> >> >> >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.1.407 / Virus Database: 268.12.10/459 - Release Date: 9/29/2006 > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.407 / Virus Database: 268.12.12/461 - Release Date: 10/2/2006 > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
