PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001390PacketFencesecuritypublic2012-03-02 10:282012-04-18 10:00
Reporterobilodeau 
Assigned Tofgaudreault 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version3.3.0Fixed in Version3.3.0 
fixed in git revision
fixed in mtn revision3bf62dc6d344cd057285a2741f3cd9804aeaaadc
Summary0001390: RADIUS Identity misuse
DescriptionThe User-Name RADIUS attribute forwarded in PacketFence's core is not the same as the one used for authentication. This could lead in stealing higher network access privileges through identity spoofing.

This is not exploitable by default as we do not rely on the User-Name for anything by default.

Only users with custom VLAN assignment extension (pf::vlan::custom) and using the $user_name parameter to assign network privileges are affected.

Details:

Our RADIUS extension runs in RADIUS' outer-tunnel after successful authentication. Outer-tunnel identity is client-side controllable and can be different than the Inner-tunnel identity. The inner-tunnel identity is the one used to perform the authentication and only a success or failure is sent to our RADIUS extension.

This possible mismatch between what is sent in the inner vs the outer is the vulnerability: I can successfully authenticate as a low-privileged user but set a high privileged user as my outer identity. The PacketFence RADIUS module is told that authentication passed and applies network access enforcement based on the outer identity (which was spoofed to the highly privileged user).

Reported by Rich Graves from Carleton College.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-03-02 10:28obilodeauNew Issue
2012-03-02 10:28obilodeauStatusnew => assigned
2012-03-02 10:28obilodeauAssigned To => fgaudreault
2012-03-02 10:28obilodeauNote Added: 0002597
2012-03-02 10:49obilodeauDescription Updated
2012-03-02 13:09obilodeauDescription Updated
2012-03-05 10:10fgaudreaultNote Added: 0002598
2012-03-05 10:14fgaudreaultNote Added: 0002599
2012-03-06 17:47fgaudreaultNote Added: 0002603
2012-03-12 13:53fgaudreaultmtn revision => 3bf62dc6d344cd057285a2741f3cd9804aeaaadc
2012-03-12 13:53fgaudreaultNote Added: 0002613
2012-03-12 13:53fgaudreaultStatusassigned => resolved
2012-03-12 13:53fgaudreaultFixed in Version => trunk
2012-03-12 13:53fgaudreaultResolutionopen => fixed
2012-04-18 09:49obilodeauTarget Version+1 => 3.3.0
2012-04-18 09:50obilodeauView Statusprivate => public
2012-04-18 09:50obilodeauFixed in Versiontrunk => 3.3.0
2012-04-18 09:59obilodeauNote Added: 0002658
2012-04-18 10:00obilodeauStatusresolved => closed

Notes
(0002597)
obilodeau   
2012-03-02 10:28   
We discussed this internally and we have a fix on the way.
(0002598)
fgaudreault   
2012-03-05 10:10   
packetfence site post-auth should look like :
post-auth {
        exec
        if (!EAP-Message) {
            packetfence
        }
        Post-Auth-Type REJECT {
                attr_filter.access_reject
        }
}

This permits non-EAP to exec the perl module while in post-auth, but it won't be exec if doing EAP.

In the packetfence-tunnel, post-auth should look like :
post-auth {
        exec
    packetfence
        Post-Auth-Type REJECT {
                attr_filter.access_reject
        }
}
(0002599)
fgaudreault   
2012-03-05 10:14   
Crap, my last answer poses potential problems for devices that are doing EAP mac authentication (Juniper) :S I don't want to check the user-name since using identity privacy, you could spoof a mac address as the username.

Will continue working on it.
(0002603)
fgaudreault   
2012-03-06 17:47   
We should do in :
- packetfence site:
if (!EAP-Type || (EAP-Type != 21 && EAP-Type != 25)) {
            packetfence
        }

- packetfence-tunnel:
post-auth {
        exec
    packetfence
        Post-Auth-Type REJECT {
                attr_filter.access_reject
        }
}
(0002613)
fgaudreault   
2012-03-12 13:53   
Fixed in devel.
(0002658)
obilodeau   
2012-04-18 09:59   
fix released in 3.3.0 last friday