[defect]: passwords are available in cleartext in a file, special characters in password can break the server

[squalou]

What type of defect/bug is this?

Unexpected behaviour (obvious or verified by project member)

How can the issue be reproduced?

NOTE : The network appliances I have use an implementation of freeradius I cannot tweak or update myself. I have opened a bug there too in case they are responsible for this defect. I also don't have access to all required debug logs. I apologize if this defect has nothing to do with freeradius itself.

Freeradius in use : 3.2.1 (debian : freeradius/bullseye-backports,now 3.2.1+dfsg-3~bpo11+1 arm64 )

There is a file called /etc/freeradius/3.0/mods-config/files/authorize which contains a cleartext version of each user and password, enclosed in quotes "

this is clearly a security issue, and also can break the server startup : Imagine your last password character is \ : as a result the cleartext string will miss its closing quote (the \ will escape it). As a result the server will fail to start.

Example observed with

someuser@somedomain Cleartest-Password := "blablablah\\""
      Tunnel-Type = 13,

...

At least, if for some reason the password must be unencrypted somewhere (which once again seems weird) , it should be properly encoded (base64 or whatever) to avoid special characters issues in plaintext files.

Log output from the FreeRADIUS daemon

2023-12-14T03:21:19+01:00 UDM-SE radiusd[4609]: /etc/freeradius/3.0/mods-config/files/authorize[246]: Parse error (check) for entry someuser@somedomain: Expected end of line or comma
2023-12-14T03:21:19+01:00 UDM-SE radiusd[4609]: Failed reading /etc/freeradius/3.0/mods-config/files/authorize
2023-12-14T03:21:19+01:00 UDM-SE radiusd[4609]: /etc/freeradius/3.0/mods-enabled/files[9]: Instantiation failed for module "files"

### Relevant log output from client utilities

_No response_

### Backtrace from LLDB or GDB

_No response_

[alandekok]

i.e. you typed the passwords into a vendor-supplied tool / web page, and that tool created an invalid configuration file for FreeRADIUS.

This isn't a FreeRADIUS issue.

At least, if for some reason the password must be unencrypted somewhere (which once again seems weird)

It's completely normal. To see why, read https://networkradius.com/articles/2021/08/23/protocols-and-password-compatibility.html

it should be properly encoded (base64 or whatever) to avoid special characters issues in plaintext files.

Or program generating the users file should escape the " character, in the same way it escapes the backslash.

But in the end we can't fix this issue. The vendor needs to fix it.

[squalou]

Thank you for the swift clarification !