freeradius-server

freeradius-server copied to clipboard

What type of defect/bug is this?

Unexpected behaviour (obvious or verified by project member)

How can the issue be reproduced?

In https://github.com/FreeRADIUS/freeradius-server/blob/be1ec67a48e4cb7769f8ae55760d5b5ba33c1a13/src/lib/json/json.c#L222C7-L222C21

case FR_TYPE_OCTETS:
		return json_object_new_string_len((char const *)data->vb_octets, data->vb_length);

present as string and in request render as "State":{"type":"octets","value":["?@\u0007?\u0000\u0000\u0000\u0003?\u0016??"]},

maybee need to present octets values in JSON as HEX?

Log output from the FreeRADIUS daemon

Fri Jan 26 07:22:49 2024: (7)      rest - Connect timeout is 3s, request timeout is 4s
Fri Jan 26 07:22:49 2024: (7)      rest - Adding custom headers:
Fri Jan 26 07:22:49 2024: (7)      rest -   X-FreeRADIUS-Section: authorize
Fri Jan 26 07:22:49 2024: (7)      rest -   X-FreeRADIUS-Server: tacacs
Fri Jan 26 07:22:49 2024: (7)      rest - Request body content-type will be "application/json"
Fri Jan 26 07:22:49 2024: (7)      rest - JSON Data: {"Packet-Body-Type":{"type":"uint8","value":["Continue"]},"User-Message":{"type":"string","value":["test"]},"Data":{"type":"octets","value":[""]},"Authentication-Continue-Flags":{"type":"uint8","value":["Unset"]},"Packet-Type":{"type":"uint32","value":["Authentication-Continue"]},"State":{"type":"octets","value":["?@\u0007?\u0000\u0000\u0000\u0003?\u0016??"]},"Client-Port":{"type":"string","value":["tty1"]},"Remote-Address":{"type":"string","value":["192.168.30.90"]},"Privilege-Level":{"type":"uint8","value":["User"]},"Authentication-Type":{"type":"uint8","value":["ASCII"]},"User-Name":{"type":"string","value":["test"]}}
Fri Jan 26 07:22:49 2024: (7)      rest - Returning 628 bytes of JSON data
Fri Jan 26 07:22:49 2024: (7)      rest - Content-Length will be 628 bytes
Fri Jan 26 07:22:49 2024: multi-handle 0x55f7d2432e10 will need servicing in 0 ms

Relevant log output from client utilities

No response

Backtrace from LLDB or GDB

No response

I suspect it's better to use hex encoding. But the problem there is that json doesn't have data types. So hex strings will still need to be double quoted.

yes, but now JSON contains unexpected characters in the string and JSON is not valid

OK. So octets is preferable.

Shouldn't be presented as hex, it's using JSON escape sequences. Maybe some chars aren't being handled correctly?

Hex really isn't correct. If you use json escape sequences the string you get out of the json decoder is the binary data. If you use hex/base64 there's a manual step for decoding.

Checking v4, we now use the json-c functions. So this is very likely to be <= v3.2 only

@levide could you check this change works?

@arr2036 sorry, I forgot to say that this is in master branch

attr value in urlencode: 0xf44007d40000000395169ad1 attr value in json: �@\u0007�\u0000\u0000\u0000\u0003�\u0016��

In that case you want to raise your bug report against json-c, and request they escape chars > 0x7E, or better, implement UTF8 char detection: https://github.com/FreeRADIUS/freeradius-server/blob/45f465b92d54d4ce1459abb4bcf5968091fda34e/src/lib/util/print.c#L39

https://github.com/json-c/json-c/blob/dabed80523fa5101e30f0ee57ba06b02beae73eb/json_object.c#L233

Hi, I encounter the same issue on docker freeradius-3.2-alpine latest. {...'Event-Timestamp': {'attr_num': 55, 'type': 'date', 'value': ['Jul 3 2024 04:45:40 UTC']}, 'Connect-Info': {'attr_num': 77, 'type': 'string', 'value': ['CONNECT 0Mbps 802.11g']}, 'EAP-Message': {'attr_num': 79, 'type': 'octets', 'value': ['\x02æ\x00\x06\r\x00']}, 'Message-Authenticator': {'attr_num': 80, 'type': 'octets', 'value': ['°=\Fà\x16ê0Ù\.QKµ[G']}, 'WLAN-Pairwise-Cipher': {'attr_num': 186, 'type': 'integer', 'value': [1027076]}, 'WLAN-Group-Cipher': {'attr_num': 187, 'type': 'integer', 'value': [1027076]}, 'WLAN-AKM-Suite': {'attr_num': 188, 'type': 'integer', 'value': [1027077]}}

@ntikhoa You might be looking at the wrong data. Since your output uses single quotes, this is not the original JSON input, JSON requires double quote. My guess is that your EAP-Message originally was "\x02\xe6\x00\x06\x0d\x00", and something in your output decided to interpret that as UTF8 instead of binary (or possibly a different encoding).

I think the easiest way to validate would to use tcpdump -i any -s 0 -A port $REST_PORT and look at the requests as the arrive at the webserver, the EAP-message should be encoded with something like \u0002\u00e6....