ssl_engine_kernel.c in mod_ssl before 2.8.24, when using "SSLVerifyClient optional" in the global virtual host configuration, does not properly enforce "SSLVerifyClient require" in a per-location context, which allows remote attackers to bypass intended access restrictions.

Index: modules/ssl/ssl\_engine\_kernel.c =================================================================== --- modules/ssl/ssl\_engine\_kernel.c (revision 264993) +++ modules/ssl/ssl\_engine\_kernel.c (working copy) @@ -406,8 +406,8 @@ (!(verify\_old & SSL\_VERIFY\_PEER) && (verify & SSL\_VERIFY\_PEER)) || - (!(verify\_old & SSL\_VERIFY\_PEER\_STRICT) && - (verify & SSL\_VERIFY\_PEER\_STRICT))) + (!(verify\_old & SSL\_VERIFY\_FAIL\_IF\_NO\_PEER\_CERT) && + (verify & SSL\_VERIFY\_FAIL\_IF\_NO\_PEER\_CERT))) { renegotiate = TRUE; /\* optimization \*/

CVE-2005-2700

The Apache HTTP server before 1.3.34, and 2.0.x before 2.0.55, when acting as an HTTP proxy, allows remote attackers to poison the web cache, bypass web application firewall protection, and conduct XSS attacks via an HTTP request with both a "Transfer-Encoding: chunked" header and a Content-Length header, which causes Apache to incorrectly handle and forward the body of the request in a way that causes the receiving server to process it as a separate HTTP request, aka "HTTP Request Smuggling."

**Bugtraq mailing list archives****A new whitepaper by Watchfire - HTTP Request Smuggling**

_From_: Ory Segal <orysegal () netvision net il>  
_Date_: Mon, 06 Jun 2005 19:09:04 +0300  

Ory Segal wrote:

> Hello,
> 
> Today, Watchfire released a new whitepaper, titled "HTTP Request Smuggling". The full paper can be found in the following link: http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf <BLOCKED::http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf\>
> 
> The paper's abstract is copied below:
> 
> "We describe a new web entity attack technique – “HTTP Request Smuggling”. The attack technique and the derived attacks are relevant to most web environments and is the result of a HTTP server or device’s failure to properly handle malformed inbound HTTP requests. HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices/entities (e.g. Cache Server, Proxy Server, Web Application Firewall, etc.) are in the data flow between the user and the web server. HTTP Request Smuggling enables various attacks – web cache poisoning, session hijacking, cross-site scripting and most serious the ability to bypass web application firewall protection. HTTP Request Smuggling sends multiple specially-crafted HTTP requests that cause the two attacked entities to see two different sets of requests, allowing the hacker to smuggle a request to one device without the other device being aware of it. In the Web Cache poisoning attack, this smuggled request will trick the cache server into unintendedly associating a URL to another URL’s page (content), and caching this content for the URL. In the Web Application Firewall attack the smuggled request could be a worm (like Nimda or Code Red) or buffer overflow attack targeting the web server. Finally, because HTTP Request Smuggling enables the attacker to insert or sneak a request into the flow it allows the attacker to manipulate the web server’s request/response sequencing which can allow for credential hijacking and other malicious outcomes."
> 
> Thank you,
> \*Ory Segal
> \*/Director of Security Research/
> Watchfire (Israel) LTD.
> Tel: +972-9-9586077, Ext.236
> Mobile: +972-54-7739359
> e-mail: osegal <BLOCKED::mailto:osegal () watchfire com> at watchfire.com

**Current thread:**

*   **A new whitepaper by Watchfire - HTTP Request Smuggling** _Ory Segal (Jun 06)_

CVE-2005-2088: Bugtraq: A new whitepaper by Watchfire

Cisco IOS 11.1(x) through 11.3(x) and 12.0(x) through 12.2(x), when configured for BGP routing, allows remote attackers to cause a denial of service (device reload) via malformed BGP (1) OPEN or (2) UPDATE messages.

**Overview**

Multiple implementations of the Border Gateway Protocol (BGP) contain vulnerabilities related to the processing of UPDATE and OPEN messages. The impacts of these vulnerabilities appear to be limited to denial of service.

**Description**

BGP (RFC 1771) is designed to exchange network reachability information between peer nodes. Information advertised by a BGP system to its peers includes timers, metrics, and paths to different Autonomous System (AS) networks. Routing between AS networks depends on BGP, and the Internet is a network of AS networks. Therefore, vulnerabilities in BGP have the potential to affect the Internet infrastructure.

Multiple BGP implementations contain vulnerabilities handling exceptional OPEN and UPDATE messages. While the details of the individual vulnerabilities are different, the impacts appear to be limited to denial of service. In addition, most BGP implementations do not accept messages from arbitrary sources. Some BGP implementations only accept TCP connections (179/tcp) from properly configured peers, and some implementations require a valid AS number in the BGP message data. To deliver malicious messages to such systems, an attacker would need to spoof a TCP connection or have access to a trusted BGP peer. The attacker may also need to know a valid AS number.

For information about specific BGP implementations, please see the Systems Affected section below.

**Impact**

A remote attacker can cause a denial of service in a vulnerable system. In most cases, the attacker would need to act as a valid BGP peer. BGP session instability can result in "flapping" and other routing problems that may adversely affect Internet traffic.

**Solution**

**Apply a patch or upgrade**  
Apply a patch or upgrade as specified by your vendor.

**Restrict BGP access**

Using access control lists (ACLs) and BGP configuration settings, restrict access to valid networks and BGP peers.

**Authenticate BGP messages**

TCP MD5 (RFC 2385), IPsec, and S-BGP provide cryptographic authentication of network connections and/or BGP messages. Various performance and key distribution issues are associated with these authentication methods.

**Use out-of-band management channels**

When possible, use an out-of-band channel, such as a separate network, to transmit BGP other management traffic.

**Vendor Information**

Filter by content: Additional information available

 Sort by:

  
**CVSS Metrics**

Group

Score

Vector

Base

Temporal

Environmental

  
**References****Acknowledgements**

These vulnerabilities were reported as a result of research done by Cisco. Thanks to Cisco for sharing this research and helping to coordinate the disclosure of information about these vulnerabilities.

This document was written by Art Manion.

**Other Information**

**CVE IDs:**

CVE-2004-0589

**Severity Metric:**

8.60

**Date Public:**

2004-06-16

**Date First Published:**

2004-06-16

**Date Last Updated:**

2004-06-28 16:09 UTC

**Document Revision:**

39

CVE-2004-0589: CERT/CC Vulnerability Note VU#784540

mod_cgid in Apache before 2.0.48, when using a threaded MPM, does not properly handle CGI redirect paths, which could cause Apache to send the output of a CGI program to the wrong client.

CVE-2003-0789

lpd daemon (in.lpd) in Solaris 8 and earlier allows remote attackers to execute arbitrary commands via a job request with a crafted control file that is not properly handled when lpd invokes a mail program. NOTE: this might be the same vulnerability as CVE-2000-1220.

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 
**List:       bugtraq
Subject:    Solaris LPD Exploit (fwd)
From:       Dave Ahmad <da () securityfocus ! com>
Date:       2001-08-31 22:08:09
\[Download RAW message or body\]**

Hey,

The exploit that was attached to this message cannot be distributed..
so below is the original message sent to BUGTRAQ without the exploit.

From the exploit:

/\*
 \* remorse
 \* Solaris 8 in.lpd remote root exploit
 \* by ron1n <shellcode@hotmail.com>
 \* July 2001
 \*
 \* Written for 7DFB/TESO members and friends. Private, do not distribute
 \* negligently, etc. etc. An unpublished vulnerability is exploited. I think
 \* this is what they call 0day warez.
 \*
 \* This is not the ISS hole -- that one doesn't seem to be exploitable on the
 \* SPARC architecture. I spent a week studying all of the lp binary and library
 \* code trying to find a nice overflow that would be exploitable on SPARC. This
 \* is the best I could come up with though. I'm disappointed because it's very
 \* similar to the old SNI/NAI BSD lpd vuln and the l0pht/@stake Linux lpd vuln.
 \*
 \* There are no printer conditions that have to be met. If the system happens
 \* to be running in.lpd, consider it owned. It can be a noisy attack; other
 \* than possible syslog locations, evidence will exist under /var/spool/lp/tmp,
 \* /var/spool/lp/requests, and the mail spool directory (/tmp).
 \*
 \* The exploit targets four programs: in.lpd, lpsched adaptor, /bin/mail, and
 \* sendmail. Obviously there are going to be differences among Solaris releases
 \* and individual configurations. For instance, the Solaris 7 version of in.lpd
 \* doesn't have IPv6 support like the Solaris 8 version does, so if your IP
 \* address doesn't reverse-resolve, in.lpd will create a different directory
 \* on each release. I've handled this now in case I do a rewrite, but Solaris 7
 \* has other issues that need to be investigated. Solaris 2.6 looks even worse.
 \* If someone hooks me up with source code, I'll try to add 7 and 2.6 support.
 \*
 \* If you're not getting results, try playing around with some command line
 \* switches or some files in the exploit tarball, particularly 'script'. The
 \* system's responses, or lack thereof, can tell you everything you need for
 \* a successful exploitation.
 \*
 \* Now you too can sleep well at night knowing that there are still ways to
 \* compromise a Solaris box remotely without relying on Sun's rpc nightmare.
 \*
 \* "Something about you is very wrong..."
 \*/

Dave Ahmad
Security Focus
www.securityfocus.com

---------- Forwarded message ----------
From: "Ricky Vludmore" <ricky2k@anonymous.to>
To: bugtraq@securityfocus.com
Subject: Solaris LPD Exploit

\[This is allegedly for an unknown vulnerability.\]

I have attached the exploit that was used against me
and then sent to me as a result of my Incidents posts.
The swarm of me-too emails leads me to believe this
is being actively exploited with the public being
none the wiser. The tar content times and the
author's timestamp place it at around two months
old.

I can only guess at the intentions for trying to keep
this below the surface. The overall depressive tone of the
exploit is as unnerving as the author's up-beat attitude
toward system intrusion, but I will admit that the author
seems to hint at deeper motives. Either way, the more
productive and mature thing to do would have been to
inform the public so that end users aren't left in the
cold with these matters.

Two people asked if the system that was compromised is x86
or sparc. It's a sparc.

In reference to:

http://archives.neohapsis.com/archives/incidents/2001-08/0417.html
http://archives.neohapsis.com/archives/incidents/2001-08/0425.html

And a final post sent earlier:

>  About four hours ago I received a post from an
>  individual who claimed to have acquired exploit
>  source for this \_\_unknown\_\_ vulnerability on the
>  "ircnet chat network" about a week ago. He/she
>  then sent me a copy upon request, saying that
>  he/she witnessed it being used by a shady
>  individual in an exchange involving this and
>  another \_\_unknown\_\_ hole in a Solaris routing
>  daemon (luckily I don't run one of those!).
>
>  I now have a copy of the exploit. Haven't tried it
>  against a patched system for that (other) printer
>  bug. I somehow managed to get it working against
>  my (currently) unpatched system.
>
>  I couldn't read a line of C if my life depended on
>  it but the comments say it's an unpublished
>  hole and that it's not the ISS one (apparently
>  they were the guys who found this other printer
>  bug). I tried searching for it in a search engine.
>  No results.
>
>  I feel it's important that the public catch wind
>  of this exploit..
>
>  securityfocus contacts? bugtraq? sun?


------------------------------------------------------------
This email was sent through the free email service at http://www.anonymous.to/
To report abuse, please visit our website and click "Contact Us."

**\[prev in list\] \[next in list\] \[prev in thread\] \[next in thread\]** 

  

Configure | About | News | Add a list | Sponsored by KoreLogic

CVE-2001-1583: 'Solaris LPD Exploit (fwd)' - MARC

Denial of service in WU-FTPD via the SITE NEWER command, which does not free memory properly.

CVE-1999-0880: IBM X-Force Exchange

Cfingerd with ALLOW_EXECUTION enabled does not properly drop privileges when it executes a program on behalf of the user, allowing local users to gain root privileges.

CVE-1999-0813: IBM X-Force Exchange

A network intrusion detection system (IDS) does not properly reassemble fragmented packets.

CVE-1999-0602

The ARP protocol allows any host to spoof ARP replies and poison the ARP cache to conduct IP address spoofing or a denial of service.

Tag

#perl