Fix radius stack overflow

[NickSampanis]

function radius_get_attribute pass by reference attr_len, which is used as length argument in strncpy. radius_get_attribute does a subtraction -2, which may have a negative result (0xffff-0xfffe for u_int16). This value will lead to stack corruption

[LocutusOfBorg]

Hi @NickSampanis sorry for taking so long to look at them, but I'm worried about this one.
I don't understand why we should use uint16 if the value won't be greater than uint8.
Can you please clarify?

If 8 bits is enough I propose to change the attr_len variable type, otherwise I propose to add a length check instead of the cast.

(maybe I'm looking at the wrong problem)

[NickSampanis]

It's ok, The cves will be published shortly and some denial of service exploits too :). This bug has to do with how the c language does mathematical calculations with non int data types. C language automatically casts non int datatypes to int in order to do arithmetic calculations. So the statement
attr_len = *(begin + 1) - 2

if the next character of the begin pointer is equal to one the result will be 0xffffffff, but because attr_len is 2 bytes it could hold only 0xffff and thats why i used the cast. Now in all my patches i am trying to wipe out the security bug without modifying the code despite what i think on how efficient is the implementation. It would be better if attr_len type is uint8 but in order to do that you should modify dissector_radius function too

[LocutusOfBorg]

Feel free to do that :D

[LocutusOfBorg]

Merging in the meanwhile

[LocutusOfBorg]

I did the change, Nick, can you please check
#635 ? thanks!