Hi, I am trying to allocate a string in Cisco-AV Pair and send it as reply attribute, It works till the length is 247 chars when it becomes 248 nothing is sent back.. and when it is > 248 radius gives malformed packet error(This is no problem) But when it is 248 and nothing is sent back. It becomes a big problem as some security risks arise. Please help update reply { Cisco-AVPair = "url-redirect-acl=Web_Auth" Cisco-AVPair += "%{exec:/bin/cat /usr/local/etc/raddb/test}" } When string length is 248 ~ echo 'Service-Type="Call-Check",User-Name="ff:ff:ff:ff:ff:ff"' | radclient -x 127.0.0.1:1812 auth testing123 Sent Access-Request Id 7 from 0.0.0.0:55619 to 127.0.0.1:1812 length 45 Service-Type = Call-Check User-Name = "ff:ff:ff:ff:ff:ff" Received Access-Accept Id 7 from 127.0.0.1:1812 to 0.0.0.0:0 length 53 Cisco-AVPair = "url-redirect-acl=Web_Auth" ~ cat test url-redirect= https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2Oqcet... ======================================================= When string length is <248 ~ echo 'Service-Type="Call-Check",User-Name="ff:ff:ff:ff:ff:ff"' | radclient -x 127.0.0.1:1812 auth testing123 Sent Access-Request Id 224 from 0.0.0.0:41832 to 127.0.0.1:1812 length 45 Service-Type = Call-Check User-Name = "ff:ff:ff:ff:ff:ff" Received Access-Accept Id 224 from 127.0.0.1:1812 to 0.0.0.0:0 length 308 Cisco-AVPair = "url-redirect-acl=Web_Auth" Cisco-AVPair = "url-redirect= https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2Oqcet... " ~ cat test url-redirect= https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2Oqcet... Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in
On Dec 28, 2018, at 3:02 AM, 8zero2 operations <8zero2ops@gmail.com> wrote:
I am trying to allocate a string in Cisco-AV Pair and send it as reply attribute, It works till the length is 247 chars when it becomes 248 nothing is sent back.. and when it is > 248 radius gives malformed packet error(This is no problem)
That "malformed packet" error shouldn't happen... Which version of the server are you running?
But when it is 248 and nothing is sent back. It becomes a big problem as some security risks arise.
The RADIUS protocol limits attributes to 253 bytes of data. For VSAs, 4 bytes of that is taken up by the Vendor ID. Cisco attributes use 2 bytes for attribute ID + length. Which leaves 247 bytes of room for actual content. You can't just put 10,000 bytes of data into a Cisco-AVPAir and expect it to work. You've got to understand the limitations of the RADIUS protocol. If you need to put more than 247 bytes of data into a Cisco-AVPair attribute, then the data needs to be split across multiple attributes. Alan DeKok.
Hi Alan, Thanks for the reply. Appreciate it, I am using 3.0.11 I absolutely understand the problem but what i am trying to point out here is sending a malformed packet or not sending a reply at all might be a better option. As what happened in my case when it was 248 bytes it didnt write anything in the reply packet(I mean this attribute was not sent in reply packet) and client got full internet whereas it was supposed to get restricted with this attribute(which is a security concern), I wasnt expecting this as redirect url was a dynamic created one. when it greater than 248 it sends a malformed packet in return which nas rejects and nothing happens, client is not given full access(which might be better, rather than sending the attribute empty) I hope i was clear. On Dec 28, 2018, at 3:02 AM, 8zero2 operations <8zero2ops@gmail.com> wrote:
I am trying to allocate a string in Cisco-AV Pair and send it as reply attribute, It works till the length is 247 chars when it becomes 248 nothing is sent back.. and when it is > 248 radius gives malformed packet error(This is no problem)
That "malformed packet" error shouldn't happen... Which version of the server are you running?
But when it is 248 and nothing is sent back. It becomes a big problem as some security risks arise.
The RADIUS protocol limits attributes to 253 bytes of data. For VSAs, 4 bytes of that is taken up by the Vendor ID. Cisco attributes use 2 bytes for attribute ID + length. Which leaves 247 bytes of room for actual content.
You can't just put 10,000 bytes of data into a Cisco-AVPAir and expect it to work. You've got to understand the limitations of the RADIUS protocol.
If you need to put more than 247 bytes of data into a Cisco-AVPair attribute, then the data needs to be split across multiple attributes.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 29, 2018, at 12:08 AM, 8zero2 operations <8zero2ops@gmail.com> wrote:
Thanks for the reply. Appreciate it, I am using 3.0.11
You really need to upgrade.
I absolutely understand the problem but what i am trying to point out here is sending a malformed packet or not sending a reply at all might be a better option.
Sending a malformed packet is never an option. I'm surprised that happens, as there are many test cases which should ensure the code is correct. Never sending a reply isn't an option either. That way the NAS thinks that the server is down. It's better to just be sure that the attributes have the correct length.
As what happened in my case when it was 248 bytes it didnt write anything in the reply packet(I mean this attribute was not sent in reply packet) and client got full internet whereas it was supposed to get restricted with this attribute(which is a security concern), I wasnt expecting this as redirect url was a dynamic created one.
That's because you're running 3.0.11, I guess. 3.0.17 and the v3.0.x head just truncate the attribute.
when it greater than 248 it sends a malformed packet in return which nas rejects and nothing happens, client is not given full access(which might be better, rather than sending the attribute empty)
The server should *never* send a malformed packet. Alan DeKok.
Alright, Thanks mate. : ) Regards, Mail: 8zero2.in@gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Sat, Dec 29, 2018 at 8:22 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2018, at 12:08 AM, 8zero2 operations <8zero2ops@gmail.com> wrote:
Thanks for the reply. Appreciate it, I am using 3.0.11
You really need to upgrade.
I absolutely understand the problem but what i am trying to point out here is sending a malformed packet or not sending a reply at all might be a better option.
Sending a malformed packet is never an option. I'm surprised that happens, as there are many test cases which should ensure the code is correct.
Never sending a reply isn't an option either. That way the NAS thinks that the server is down.
It's better to just be sure that the attributes have the correct length.
As what happened in my case when it was 248 bytes it didnt write anything in the reply packet(I mean this attribute was not sent in reply packet) and client got full internet whereas it was supposed to get restricted with this attribute(which is a security concern), I wasnt expecting this as redirect url was a dynamic created one.
That's because you're running 3.0.11, I guess. 3.0.17 and the v3.0.x head just truncate the attribute.
when it greater than 248 it sends a malformed packet in return which nas rejects and nothing happens, client is not given full access(which might be better, rather than sending the attribute empty)
The server should *never* send a malformed packet.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
8zero2 operations -
Alan DeKok