REG: Cisco-AV Pair not sent

classic Classic list List threaded Threaded
5 messages Options
| Threaded
Open this post in threaded view
|

REG: Cisco-AV Pair not sent

8zero2 operations
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%2B2OqcetWBqgjlDGIDPrgIsFzCJNP0JtON2V4%2BgAJ3y2nOKZNUihAERglbTdfgep3Y%2Fo59YcsXfJp%2B%2FzfrOhbMjHA9MPVKlkUcgL8Slhkb%2BXHtHQGs8mz7du%2Fq%2FHgBqANl94lEhHTOe0udJJASNxQw%3D

=======================================================

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=
<a href="https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2OqcetWBqgjlDGIDPrgIsFzCJNP0JtON2V4%2BgAJ3y2nOKZNUihAERglbTdfgep3Y%2Fo59YcsXfJp%2B%2FzfrOhbMjHA9MPVKlkUcgL8Slhkb%2BXHtHQGs8mz7du%2Fq%2FHgBqANl94lEhHTOe0udJJASNxQw%3">https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2OqcetWBqgjlDGIDPrgIsFzCJNP0JtON2V4%2BgAJ3y2nOKZNUihAERglbTdfgep3Y%2Fo59YcsXfJp%2B%2FzfrOhbMjHA9MPVKlkUcgL8Slhkb%2BXHtHQGs8mz7du%2Fq%2FHgBqANl94lEhHTOe0udJJASNxQw%3
"

~ cat test

url-redirect=
<a href="https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2OqcetWBqgjlDGIDPrgIsFzCJNP0JtON2V4%2BgAJ3y2nOKZNUihAERglbTdfgep3Y%2Fo59YcsXfJp%2B%2FzfrOhbMjHA9MPVKlkUcgL8Slhkb%2BXHtHQGs8mz7du%2Fq%2FHgBqANl94lEhHTOe0udJJASNxQw%3">https://abcdef.abc.in:8443/register.php?eu=kMd3HIyURkpxYd%2BxLUCYTG%2B2OqcetWBqgjlDGIDPrgIsFzCJNP0JtON2V4%2BgAJ3y2nOKZNUihAERglbTdfgep3Y%2Fo59YcsXfJp%2B%2FzfrOhbMjHA9MPVKlkUcgL8Slhkb%2BXHtHQGs8mz7du%2Fq%2FHgBqANl94lEhHTOe0udJJASNxQw%3


Regards,
Mail: [hidden email]
Facebook: www.facebook.com/8zero2
Twitter: @8zero2_in
Blog: blog.8zero2.in
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: REG: Cisco-AV Pair not sent

Alan DeKok-2
On Dec 28, 2018, at 3:02 AM, 8zero2 operations <[hidden email]> 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
| Threaded
Open this post in threaded view
|

Re: REG: Cisco-AV Pair not sent

8zero2 operations
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 <[hidden email]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: REG: Cisco-AV Pair not sent

Alan DeKok-2
On Dec 29, 2018, at 12:08 AM, 8zero2 operations <[hidden email]> 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
| Threaded
Open this post in threaded view
|

Re: REG: Cisco-AV Pair not sent

8zero2 operations
Alright, Thanks mate. : )
Regards,
Mail: [hidden email]
Facebook: www.facebook.com/8zero2
Twitter: @8zero2_in
Blog: blog.8zero2.in



On Sat, Dec 29, 2018 at 8:22 PM Alan DeKok <[hidden email]>
wrote:

> On Dec 29, 2018, at 12:08 AM, 8zero2 operations <[hidden email]>
> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html