Re: [radsecproxy] Rather severe bug in 1.8.0 : secret field content erroneously interpreted - radsecproxy

12 Sep 2019

      Hi

Whatever software you use, you need to deal with some sort of escaping of user-supplied
secrets because you can't predict what characters may be used. In FreeRADIUS, quote
characters and spaces would be problematic in secrets; in radsecproxy, percents and spaces
are.

We deal with the escaping in the script that generates our radsecproxy configuration.
I've some python I could share when I get back to a real PC.

- Guy

Sent from my cell phone. Please excuse brevity and spelling.

On 12 Sep 2019 16:47, Christian Claveleira &lt;Christian.Claveleira(a)renater.fr&gt;
wrote:
Fabian Mauchle wrote on 12/09/2019 15:54:
...
  Hi Christian,

 On 12.09.19, 15:34, "radsecproxy on behalf of Christian Claveleira"
&lt;radsecproxy-bounces(a)lists.nordu.net on behalf of Christian.Claveleira(a)renater.fr&gt;
wrote:
      it seems the content of the secret string is interpreted when it contains a
"%" :

      when a client (or server) declaration contains
      secret   fht8CD%E7am

      it is interpreted as
      getgenericconfig: block client xxxx.yyyyy: secret = fht8CDçam

      One can see "%E7" is translated as the "ç" character.

 This case is mentioned in the manpage radsecproxy.conf(5):
 If you want to write a % and not use this decoding, you may of course write % in hex;
i.e., %25.

 Regards,
 Fabian

 --
 SWITCH
 Fabian Mauchle, Network Engineer
 Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
 Phone +41 44 268 15 30, direct +41 44 268 15 39
 fabian.mauchle(a)switch.ch, http://www.switch.ch

 Hi Fabian,

Sorry for not have seen that but we don't choose the secrets used : the
clients/servers administrators choose their secret which
are put in configuration files for FreeRadius (in production) and radsecproxy (for
evaluation). It's not expected to have to
translate the content of the secret string :-\.

Regards,
Christian