Francesco Paolo Lovergine [EMAIL PROTECTED] wrote:
The true problem is admin inconsistency ;) Unfortunately
:::10.0.0.0/24 is a perfectly valid CIDR notation, but IS NOT what a
naive user would expect, because IPV6 CIDR are on a 128bit range. So using
that notation indeed open the daemon
On Wed, May 10, 2006 at 10:45:49AM +0200, Julien BLACHE wrote:
Francesco Paolo Lovergine [EMAIL PROTECTED] wrote:
The true problem is admin inconsistency ;) Unfortunately
:::10.0.0.0/24 is a perfectly valid CIDR notation, but IS NOT what a
naive user would expect, because IPV6 CIDR
On Wed, May 10, 2006 at 07:29:30AM +0200, Julien BLACHE wrote:
Francesco Paolo Lovergine [EMAIL PROTECTED] wrote:
Hi,
Huh? It's a IPv6 address, followed by a slash, followed by the number
of significant bits in decimal. Just like IPv4.
Sorry, that's not what I meant.
Processing commands for [EMAIL PROTECTED]:
severity 365464 important
Bug#365464: proftpd: net ACLs are buggy
Severity set to `important'.
tags 365464 - security
Bug#365464: proftpd: net ACLs are buggy
Tags were: fixed-upstream pending patch confirmed upstream security
Tags removed: security
severity 365464 important
tags 365464 - security
thanks
This is more a configuration issue than a true bug. A proper configured
system (i.e. full 128bits CIDR) has no problem at all.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Processing commands for [EMAIL PROTECTED]:
tags 365464 + patch
Bug#365464: proftpd: net ACLs are buggy
Tags were: confirmed upstream security
Tags added: patch
tags 365464 + pending
Bug#365464: proftpd: net ACLs are buggy
Tags were: patch confirmed upstream security
Tags added: pending
tags
tags 365464 + patch
tags 365464 + pending
tags 365464 + fixed-upstream
thanks
An upstream patch is now available to refuse CIDR notation in ipv6
addresses. It seems ok to me to manage the issue.
Would you please confirm that, if you are able to patch yourself the package?
Else i'll go straight
Francesco Paolo Lovergine [EMAIL PROTECTED] wrote:
Hi,
An upstream patch is now available to refuse CIDR notation in ipv6
addresses. It seems ok to me to manage the issue.
Would you please confirm that, if you are able to patch yourself the package?
Else i'll go straight with -7 with that.
On Tue, May 09, 2006 at 01:43:14PM +0200, Julien BLACHE wrote:
An upstream patch is now available to refuse CIDR notation in ipv6
addresses. It seems ok to me to manage the issue.
Would you please confirm that, if you are able to patch yourself the
package?
Else i'll go straight with
* Francesco Paolo Lovergine:
Refusing IPv6 subnets doesn't qualify as a fix for this issue IMHO,
but at least it'll fix the hole in the meantime. I wonder how this
code can end up in a stable release.
I'm not an IPv6 expert but AFAIK IPv4 CIDR notation is simply a non
sense in 128bit
On Tue, May 09, 2006 at 06:18:34PM +0200, Florian Weimer wrote:
* Francesco Paolo Lovergine:
Refusing IPv6 subnets doesn't qualify as a fix for this issue IMHO,
but at least it'll fix the hole in the meantime. I wonder how this
code can end up in a stable release.
I'm not an IPv6
* Francesco Paolo Lovergine:
According to my notes (I'm offline at the moment), RFC 3513 specifies
a syntax for IPv6 prefixes. The syntax is similar to IPv4 prefixes:
0123:4567:89ab:cdef:0123:4567:89ab:cde0/124
Which is completely different from the ipv4 cidr indeed.
Huh? It's a
On Tue, May 09, 2006 at 09:37:41PM +0200, Florian Weimer wrote:
* Francesco Paolo Lovergine:
According to my notes (I'm offline at the moment), RFC 3513 specifies
a syntax for IPv6 prefixes. The syntax is similar to IPv4 prefixes:
0123:4567:89ab:cdef:0123:4567:89ab:cde0/124
Francesco Paolo Lovergine [EMAIL PROTECTED] wrote:
Hi,
Huh? It's a IPv6 address, followed by a slash, followed by the number
of significant bits in decimal. Just like IPv4.
Sorry, that's not what I meant.
:::192.168.0.0/124 is correct, :::192.168.0.0/24 not.
because the second
Processing commands for [EMAIL PROTECTED]:
tags 365464 + upstream
Bug#365464: proftpd: net ACLs are buggy
Tags were: security
Tags added: upstream
tags 365464 + confirmed
Bug#365464: proftpd: net ACLs are buggy
Tags were: upstream security
Tags added: confirmed
thanks
Stopping processing
tags 365464 + upstream
tags 365464 + confirmed
thanks
See #2785 on proftpd bugzilla.
--
Francesco P. Lovergine
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: proftpd
Version: 1.3.0-4
Severity: grave
Tags: security
Justification: user security hole
Hi,
Net ACLs in proftpd 1.3.0 seem to be buggy. Specifying a network using either
CIDR notation or a wildcard leads to proftpd granting access to every clients
regardless of their IP address.
My
17 matches
Mail list logo
