Bug #16128
open
if_pppoe: PHP password handling
0%
Description
A user reports (https://forum.netgate.com/topic/197026/25-03-b-20250306-0140-if_pppoe-kernel-module-chap-failure/10 ) that a leading space in a password used to be ignored as it was written to the mpd5 configuration file without quotes around it.
That's not the case with if_pppoe, so it's considered part of the password.
The if_pppoe behaviour is probably what we want, but we ought to at least document this for TAC.
We should also check if we're correctly handling passwords with symbols such as ", ', \, ... in them here: https://gitlab.netgate.com/pfSense/pfSense/-/blob/master/src/etc/inc/interfaces.inc?ref_type=heads#L2311
Updated by Bill Meeks 2 months ago
Just a thought -- but it would potentially be helpful if password validation logic would check for leading or trailing spaces in entered passwords and warn the user when saving by displaying the standard pfSense warning message at the top of the page. Make it a warning and not a fail, so the user can proceed with the space(s) if desired. Unintended spaces in passwords have been the source of several mysterious problems <grin>.
Updated by Kris Phillips about 1 month ago
- Status changed from New to Confirmed
Marking as Confirmed for now, since this is a known difference in behavior.
Updated by Scott Ashcroft 10 days ago
Passwords which begin with exclamation mark (!) are broken see:
https://forum.netgate.com/post/1216202
The proper fix would be to base64 encode the password before passing it to the command line and so avoid all the escaping issues.
The command would then do the decode before passing it to the kernel module.
In theory PPP passwords could contain all sorts of mad characters as all bytes values including NUL are valid. Passing them directly as a command line argument will always be dangerous.
Having the connection not work is probably the least worst thing that could happen.