Bug 98916 - Listen statement in ssl.conf allows IPv4-mapped IPv6 addresses
Listen statement in ssl.conf allows IPv4-mapped IPv6 addresses
Product: Red Hat Linux
Classification: Retired
Component: httpd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2003-07-10 07:52 EDT by Joe Orton
Modified: 2007-04-18 12:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-08-25 14:00:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joe Orton 2003-07-10 07:52:36 EDT
The default ssl.conf has a bad default of:

  Listen 443

which means that, on a server with a public IPv6 interface configured,
the server will accept connections using IPv6 sockets from IPv4-mapped addresses
on the SSL port by default.  This means that allow/deny address matching will
not work on IPv4 addresses; in a configuration like:

  <Location /secrets>
    Order allow,deny
    Allow from all
    Deny from 10.20.30.*

the Deny directive will not match the IPv6-mapped addresses, so will allow
clients to connect from 10.20.30.* via SSL.

mod_ssl package in 8.0, 9

Mitigating factors:
IPv6 not in widespread use.

It is more common to use address matching in deny,allow order, with address
ranges specified in "Allow" statements; a false negative match on an Allow
statement is not a security issue.
Comment 1 Joe Orton 2003-07-10 08:03:47 EDT
This affects non-SSL connections, the default httpd.conf has the same problem:
  Listen 80
Comment 2 Joe Orton 2003-08-25 14:00:39 EDT
The theory was sound but the testing wasn't, there is code in 2.0 to deal with
this correctly; an "allow" or "deny" restriction based on an IPv4 address or
subnet is tested against IPv4-mapped IPv6 addresses in the expected manner.

Note You need to log in before you can comment on or make changes to this bug.