Glitches in the expr engine?
So today I had one of my sites deploy the new moonshot-targeted-ids file in the 3.0.x branch. Everything so far, so good. Then I ask him to use a random string as the salt (which contained a closing curly bracket). The output was definitely *not* what was expected. This example below (salt = 'changeme}') illustrates the problem: -- begin -- (13) policy moonshot_host_tid.post-auth { (13) if (&outer.request:GSS-Acceptor-Host-Name) { (13) if (&outer.request:GSS-Acceptor-Host-Name) -> TRUE (13) if (&outer.request:GSS-Acceptor-Host-Name) { (13) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme}%{tolower:%{outer.request:GSS-Acceptor-Host -Name}}}" =~ /^([^ ]+)([ ]*)$/) { (13) Executing: /usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 steve@example.comchangeme: (13) Program returned code (0) and output '86b8d074-fe42-5dfa-b160-3fb770a96c98' (13) EXPAND %{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme}%{tolower:%{outer.request:GSS-Acceptor-Host -Name}}} (13) --> 86b8d074-fe42-5dfa-b160-3fb770a96c98debian8.localdomain} (13) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme}%{tolower:%{outer.request:GSS-Acceptor-Host -Name}}}" =~ /^([^ ]+)([ ]*)$/) -> TRUE (13) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme}%{tolower:%{outer.request:GSS-Acceptor-Host -Name}}}" =~ /^([^ ]+)([ ]*)$/) { (13) update outer.session-state { (13) EXPAND %{1}@%{tolower:%{request:Realm}} (13) --> 86b8d074-fe42-5dfa-b160-3fb770a96c98debian8.localdomain}@example.com (13) Moonshot-Host-TargetedId := "86b8d074-fe42-5dfa-b160-3fb770a96c98debian8.localdomain}@example.com" (13) } # update outer.session-state = noop (13) } # if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme}%{tolower:%{outer.request:GSS-Acceptor-Host -Name}}}" =~ /^([^ ]+)([ ]*)$/) = noop (13) } # if (&outer.request:GSS-Acceptor-Host-Name) = noop (13) } # policy moonshot_host_tid.post-auth = noop (13) update { (13) &outer.session-state:EAP-Channel-Binding-Message += &reply:EAP-Channel-Binding-Message -> 0x02001b01a406686f7374a51564656269616e382e6c6f63616c646f6d61696e (13) &outer.session-state:EAP-Message += &reply:EAP-Message -> 0x03010004 (13) &outer.session-state:Message-Authenticator += &reply:Message-Authenticator -> 0x00000000000000000000000000000000 (13) &outer.session-state:Stripped-User-Name += &reply:Stripped-User-Name -> 'steve' (13) } # update = noop -- end -- So... What is the solution to this? Expect people to escape the curly brackets in the salt? If so, I'll update the documentation to say this. The below is the correct output, by the way: -- begin -- (29) post-auth { (29) policy moonshot_host_tid.post-auth { (29) if (&outer.request:GSS-Acceptor-Host-Name) { (29) if (&outer.request:GSS-Acceptor-Host-Name) -> TRUE (29) if (&outer.request:GSS-Acceptor-Host-Name) { (29) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme\}%{tolower:%{outer.request:GSS-Acceptor-Hos t-Name}}}" =~ /^([^ ]+)([ ]*)$/) { (29) Executing: /usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 steve@example.comchangeme\}debian8.localdomain: (29) Program returned code (0) and output '6467194a-b3f4-56b7-bd30-6f0afac50c65' (29) EXPAND %{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme\}%{tolower:%{outer.request:GSS-Acceptor-Hos t-Name}}} (29) --> 6467194a-b3f4-56b7-bd30-6f0afac50c65 (29) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme\}%{tolower:%{outer.request:GSS-Acceptor-Hos t-Name}}}" =~ /^([^ ]+)([ ]*)$/) -> TRUE (29) if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme\}%{tolower:%{outer.request:GSS-Acceptor-Hos t-Name}}}" =~ /^([^ ]+)([ ]*)$/) { (29) update outer.session-state { (29) EXPAND %{1}@%{tolower:%{request:Realm}} (29) --> 6467194a-b3f4-56b7-bd30-6f0afac50c65@example.com (29) Moonshot-Host-TargetedId := "6467194a-b3f4-56b7-bd30-6f0afac50c65@example.com" (29) } # update outer.session-state = noop (29) } # if ("%{echo:/usr/bin/uuid -v 5 a574a04e-b7ff-4850-aa24-a8599c7de1c6 %{tolower:%{User-Name}}changeme\}%{tolower:%{outer.request:GSS-Acceptor-Hos t-Name}}}" =~ /^([^ ]+)([ ]*)$/) = noop (29) } # if (&outer.request:GSS-Acceptor-Host-Name) = noop (29) } # policy moonshot_host_tid.post-auth = noop (29) update { (29) &outer.session-state:EAP-Channel-Binding-Message += &reply:EAP-Channel-Binding-Message -> 0x02001b01a406686f7374a51564656269616e382e6c6f63616c646f6d61696e (29) &outer.session-state:EAP-Message += &reply:EAP-Message -> 0x03010004 (29) &outer.session-state:Message-Authenticator += &reply:Message-Authenticator -> 0x00000000000000000000000000000000 (29) &outer.session-state:Stripped-User-Name += &reply:Stripped-User-Name -> 'steve' (29) } # update = noop -- end -- Advice gladly accepted :-) With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Mar 2, 2017, at 2:49 PM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
So today I had one of my sites deploy the new moonshot-targeted-ids file in the 3.0.x branch.
Everything so far, so good. Then I ask him to use a random string as the salt (which contained a closing curly bracket). The output was definitely *not* what was expected. This example below (salt = 'changeme}') illustrates the problem:
Yes, you need to escape curly close braces in xlat expansions. The escape sequence is %} -Arran
Everything so far, so good. Then I ask him to use a random string as the salt (which contained a closing curly bracket). The output was definitely *not* what was expected. This example below (salt = 'changeme}') illustrates the problem:
Yes, you need to escape curly close braces in xlat expansions.
Would it be safe to say that if I add another check into the output to send a reject if the output contains a { or a } (which it never should), it should be acceptable? If so, I'll submit a PR for that. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Mar 7, 2017, at 11:15 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Everything so far, so good. Then I ask him to use a random string as the salt (which contained a closing curly bracket). The output was definitely *not* what was expected. This example below (salt = 'changeme}') illustrates the problem:
Yes, you need to escape curly close braces in xlat expansions.
Would it be safe to say that if I add another check into the output to send a reject if the output contains a { or a } (which it never should), it should be acceptable?
I'm pretty sure it's only an issue if it's '}'. But sure... -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Would it be safe to say that if I add another check into the output to send a reject if the output contains a { or a } (which it never should), it should be acceptable?
I'm pretty sure it's only an issue if it's '}'. But sure...
Well, if I use '%{' in the string and escape the % with a \, I get 'rad_expand_xlat: Invalid variable expansion passed as argument' as error message, but the output is nothing, which of course means nothing gets set. So I guess it's only if the } gets involved that things go badly wrong (i.e. that the resulting attribute contains a }, part of the salt, and part of the host/realm/COI name). I'll submit a PR for the updates. Ta! Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
participants (2)
-
Arran Cudbard-Bell -
Stefan Paetow