Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Saturday, 24 February 2018 03:44:07 UTC, Alex Dubois wrote:
> On Tuesday, 20 February 2018 13:04:15 UTC, Wojtek Porczyk wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
> > wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
> > > wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > >
> > > I would argue against the @ sign on account that it is a special
> > > character
> > > in bash as well.
> > >
> > > Search for it here;
> > > https://linux.die.net/man/1/bash
> > > I don't immediately see a way to exploit it, but why risk it?
> >
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was
> > to list available characters (POSIX Portable Character Set [1]) and
> > substract
> > the characters that are special to some relevant things:
> > - - qube name: a-z A-Z 0-9 _ -
> > - - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
> > - - POSIX shell reserved words [3]: ! { }
> > - - non-POSIX things [3]: [ ]
> > - - special qrexec character: +
> > - - path separators (POSIX and NT): / \ :
> > - - regular expressions: ^. (and other already excluded)
> >
> > This leaves: '\0\a\b,@'. The point is, all characters are special to
> > something. I'm sure if I searched for more "special" characters, I'd find
> > them
> > ('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
> > ',' we use in other context in policy). So I stopped there and by consensus
> > we
> > picked '@'.
> >
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
> >
> > [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
> > [2]
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
> > [3]
> > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
> >
> >
> > - --
> > pozdrawiam / best regards _.-._
> > Wojtek Porczyk .-^' '^-.
> > Invisible Things Lab |'-.-^-.-'|
> > | | | |
> > I do not fear computers,| '-.-' |
> > I fear lack of them.'-._ : ,-'
> > -- Isaac Asimov `^-^-_>
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2
> >
> > iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
> > 24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
> > SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
> > 0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
> > 72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
> > MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
> > TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
> > BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
> > 9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
> > 2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
> > /PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
> > t9joU8uqhcS4Wt6nA9lh
> > =EN6G
> > -END PGP SIGNATURE-
>
> I fail to grasp fully the problem. Could you maybe provide an example of an
> attack (sourceVM script and sourceVMname, policy and targetVM script).
>
> After multiple rewording on my understanding and reading some doc I have the
> feeling that I am getting closer.
>
> The policy validation service evaluate the policy file and does not
> interpolate the string with $. It compares $variable (as a string) with a set
> of strings (i.e. $dispvm, $tag, etc...). Are you not able to white-list this
> part?
> Or to use non authorized character in the policy file but keep $ in the
> sourceVMscript (is it what you suggested). Or use a trailing character as
> well.
> i.e. anon-whonix %dispvm% allow,target=%dispvm%:anon-whonix-dvm
>
> Another option might be to play with the formatting of the policy files
> (multiple line per rule)?
> i.e. 0 anon-whonix 1 dispvm allow,target=1 dispvm:0 anon-whonix-dvm
> ('1 ' is $ '0 ' no $).
>
> Is there not also a problem after the policy evaluation with the string
> substitution itself in Dom0? policy should be more explicit when no argument
> is allowed.
> i.e.:
> /etc/qubes-rpc/policy/FileCopy+ (default argument policy)
> /etc/qubes-rpc/policy/FileCopy (no argument policy)
> /etc/qubes-rpc/policy/FileCopy+blah (argument blah policy)
Please ignore. reading the commits was the for me. Apologies for the noise.
--
You received this message because you are subscribed to the Google
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 13:04:15 UTC, Wojtek Porczyk wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > > We've decided to deprecate the '$' character from qrexec-related usage.
> > > Instead, to denote special tokens, we will use the '@' character,
> > > which we believe is less likely to be interpreted in a special way
> > > by the relevant software.
> >
> > I would argue against the @ sign on account that it is a special character
> > in bash as well.
> >
> > Search for it here;
> > https://linux.die.net/man/1/bash
> > I don't immediately see a way to exploit it, but why risk it?
>
> We absolutely need a special character that is not allowed in qube name to
> make the special tokens immediately obvious in policy. The process I used was
> to list available characters (POSIX Portable Character Set [1]) and substract
> the characters that are special to some relevant things:
> - - qube name: a-z A-Z 0-9 _ -
> - - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
> - - POSIX shell reserved words [3]: ! { }
> - - non-POSIX things [3]: [ ]
> - - special qrexec character: +
> - - path separators (POSIX and NT): / \ :
> - - regular expressions: ^. (and other already excluded)
>
> This leaves: '\0\a\b,@'. The point is, all characters are special to
> something. I'm sure if I searched for more "special" characters, I'd find them
> ('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
> ',' we use in other context in policy). So I stopped there and by consensus we
> picked '@'.
>
> If I missed something, could you please point out? I know shell just good
> enough to know that it's not possible to know every shell quirk. :)
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
> [2]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
> [3]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
>
>
> - --
> pozdrawiam / best regards _.-._
> Wojtek Porczyk .-^' '^-.
> Invisible Things Lab |'-.-^-.-'|
> | | | |
> I do not fear computers,| '-.-' |
> I fear lack of them.'-._ : ,-'
> -- Isaac Asimov `^-^-_>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
> 24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
> SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
> 0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
> 72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
> MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
> TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
> BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
> 9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
> 2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
> /PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
> t9joU8uqhcS4Wt6nA9lh
> =EN6G
> -END PGP SIGNATURE-
I fail to grasp fully the problem. Could you maybe provide an example of an
attack (sourceVM script and sourceVMname, policy and targetVM script).
After multiple rewording on my understanding and reading some doc I have the
feeling that I am getting closer.
The policy validation service evaluate the policy file and does not interpolate
the string with $. It compares $variable (as a string) with a set of strings
(i.e. $dispvm, $tag, etc...). Are you not able to white-list this part?
Or to use non authorized character in the policy file but keep $ in the
sourceVMscript (is it what you suggested). Or use a trailing character as well.
i.e. anon-whonix %dispvm% allow,target=%dispvm%:anon-whonix-dvm
Another option might be to play with the formatting of the policy files
(multiple line per rule)?
i.e. 0 anon-whonix 1 dispvm allow,target=1 dispvm:0 anon-whonix-dvm
('1 ' is $ '0 ' no $).
Is there not also a problem after the policy evaluation with the string
substitution itself in Dom0? policy should be more explicit when no argument is
allowed.
i.e.:
/etc/qubes-rpc/policy/FileCopy+ (default argument policy)
/etc/qubes-rpc/policy/FileCopy (no argument policy)
/etc/qubes-rpc/policy/FileCopy+blah (argument blah policy)
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/e855daee-13e4-4f64-b9c7-975cd53f9ad7%40googlegroups.com.
For more
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Wed, February 21, 2018 4:41 pm, qubenix wrote: >> So let me be blunt as this is likely the last email from me to qubes >> > anyway; > > Bye, I'm happy to see you go away finally. It was killing me inside that > you were working on the new gui controller. Fuck off back to bcash. Tom had some constructive criticism to offer, which is healthy. I don't think your response is particularly constructive or appropriate for the mailing lists, however. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2e43f714c9a042127c35756526d64771.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
> So let me be blunt as this is likely the last email from me to qubes anyway; Bye, I'm happy to see you go away finally. It was killing me inside that you were working on the new gui controller. Fuck off back to bcash. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2b004517-b9b8-6507-dd04-173728dc3999%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Wednesday, 21 February 2018 12:12:06 CET Wojtek Porczyk wrote: > This is bad UX. This is frustrating, I spent too many emails making the point clear that this is an API level escape token. Not a user-visible one, and then you respond to the thread showing you still completely missed that. So let me be blunt as this is likely the last email from me to qubes anyway; Fact: Variables given to qrexec are going to be replaced with the actual relevant value. For instance bash takes`ls *` and replaces the star with the actual values _before_ calling ls. Ls or any executable does not have to deal with things like star or dollar sign etc. Your and Marek complaints are that you need to escape the variables when you pass them on to the target VM handler. If you are indeed doing that, you are doing it wrong and you can wait for the next security bulletin like the one we are discussing right now. The point of a variable that is passed from a VM to the dom0 qrexec daemon is that your source VM doesn't have to know about who is $adminVM or what is the actually started dispVM's name. QRexec daemon (in dom0) should do the variable replacement before the user request leaves qrexec-daemon running in dom0. Just like bash does the replacement before it forwards the command-line. Again, if you do not do the variable replacement there, but instead pass it through unvalidated and unrelated software, you are going to continue having security flaws. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/3526761.85MCzvWFfn%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel > wrote: > > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki > wrote: > > > > We've decided to deprecate the '$' character from qrexec-related > > > > usage. > > > > Instead, to denote special tokens, we will use the '@' character, > > > > which we believe is less likely to be interpreted in a special way > > > > by the relevant software. > > > > > > I would argue against the @ sign on account that it is a special > > > character in bash as well. > > > > > > I don't immediately see a way to exploit it, but why risk it? > > > > We absolutely need a special character that is not allowed in qube name to > > make the special tokens immediately obvious in policy. The process I used > > was to list available characters (POSIX Portable Character Set [1]) > [] > > If I missed something, could you please point out? I know shell just good > > enough to know that it's not possible to know every shell quirk. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Thank you for the suggestion, but I don't think it's correct. The character has to be input in at least two places: in /etc/qubes-rpc/policy as the second token (destination) on the line and as argument to qrexec-client[-vm] executable. Using any of the common editors, any language-specific keyboard layout, and any common encoding. Most people have UTF-8, or ISO-8859-*, but we don't exclude the possibility to have admin qube on Windows -- there was at least one serious attempt -- so this brings UTF-16 and Windows-125*. As and example, may I use ÿ character you provided: 1) You're right the codepoint is U+00FF, but UTF-8 encoding is actually "\xc3\xbf", so no, we cannot use it. 2) I don't have it on my keyboard. So anytime I have to input one of those characters, I search all the modifiers for the right one (ý? no. ŷ? neither. ỹ? my font has trouble with that, is that even a letter? ý? tried this one already...). I don't have real data, but I think most people don't even know where to start looking for this and in the optimistic case will end up sourcing it from gucharmap or equivalent. This is bad UX. Maybe there is a character outside portable charset that is portable and writable enough, but I don't know of any. I haven't thought there is hope enough to actually find one, so I didn't bother searching. That's why I've asked. Again, thanks for your review. I think it's helpful, because this change was made behind community's back (for obvious reasons), fast, and in very limited group of people. I wasn't sure if we didn't make some mistake, so the best what I could hope for was to explain myself and get ex post facto review, which you provided. - -- pozdrawiam / best regards _.-._ Wojtek Porczyk .-^' '^-. Invisible Things Lab |'-.-^-.-'| | | | | I do not fear computers,| '-.-' | I fear lack of them.'-._ : ,-' -- Isaac Asimov `^-^-_> -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJajVQEAAoJEL9r2TIQOiNRpbUQAJjEEAk+rKZOrFjjMkG3WQem /KNCL9gfVt3T6/keBBuEwfX3XcOIiO/FBWNfcf6dxeBGGcMHHQn0pd4Ucj/HZw8b 0/s63gjXH+ru7m4x2VW/3uDI4igkic6UUYPVHDB0sQtbTvGGWsr5pPJxcx7JgbwX +mJmDgt7i/9Y3lAGEva5ex+q7WG4hJd8ArgnJGAVnp7MrTgIduHW1/2QufC6uvvE gRRc3gbZK5FkT5Yg38UumE4sNcmnV0Nvu3m+o/g/cBcEER7wO81XW6TKFj0Ok/Bg Ostsov9NwO3iGv0usSUvMKfw7Aac3VK9SsW0r5sxA/QFe9jVvasVnmvIrxTRwwL+ W+gP5piagxgphLhUcR6LwyEhRPWzb06iDaaztXnLXyInWFEGdei1ATmlQNI0Rmno pNh/QLQqS6YF+hAl8LxSkOj3tjcg7MTYl00y9Z6ePJRUDA84s1hlWT43agWNN4L3 SX55/UzTU8DlhcduL3WmY6DVIKKlfE2Q82VorkprY6i/u/d7fdCblYLOtatZh2JB OK1ZFOprRlAJodYQMUws7o8cDgY3LxfgKX45PC23DJG6o5CDM+WoqmUw72uxMFft jRE299HwUV3qfzxm9/bjLPJqgnP+nSFnY/4J02iHUQxkg3Xb9ibKxFmTWhnf78zd REwcpFmrrjnrVVy14CZ2 =wkxM -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 19:41:19 CET Marek Marczykowski-Górecki wrote: > > On the 'other' side of qrexec (on dom0) you have perfect control over > > the > > situation and you also don't have any need for recoding or encodings or > > anything like that. It still is just 8 bits data, not encoded. > > And then, after policy evaluation, you pass that data to actual service > to execute the operation (which may be in dom0 or another VM). Yes, WITHOUT the escape character. Remember, you escape the special names of VM names that dom0 will substitute. “$adminvm” doesn't end up being the string you offer to qubesd, the string “dom0” is. Likewise; you don't start a service in Dispvm18431 and send it the text “$dispvm”. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2032074.AZcuCm27fB%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > > The thing you have to rememeber is that the escape character never needs > > > to be typed by the user. > > > In QRexec you are defining an API, applications like qvm-run are using > > > that API. What the user passes into qvm-run and what is actually sent > > > to dom0 does not have to be identical. > > > > In theory yes, but this would introduce more complexity to this code > > (taking care where which encoding is used etc). > > I read the code, there is no encoding. > You correctly used the POSIX Portable Character Set for text. So no need > for encoding. > When you use the qrexec API you just sent a struct with some arrays of bytes > for VM names. > In your qrexec code you use an array of unsigned chars. Also, no encoding. > > The point is that you use encodings only when you have **text** with > characters > 127. Which you don't allow. > > The problem you fear doesn't exist. > > The reason is because when accepting user-input you use encodings. > > When your app starts talking to qrexec/qubsed there is no longer any > encoding. Just an 8-bit bytearray. The text has been standardized. > > On the 'other' side of qrexec (on dom0) you have perfect control over the > situation and you also don't have any need for recoding or encodings or > anything like that. It still is just 8 bits data, not encoded. And then, after policy evaluation, you pass that data to actual service to execute the operation (which may be in dom0 or another VM). > > > I guess you do the translation currently as well; '$' turns into '@' in > > > your new code. > > > > > > The consequence of this is that you don't have to limit yourself to the > > > posix list. > > > Using the portable characters set for a non-character simply isn't > > > needed. > > > > > > So, knowing that your API is actually based on 8-bit characters and not > > > 7 > > > bits which you are limiting yourself to, my suggestion is to take > > > something above 127 and below 256 as a special char. > > > Most fun one would be “ÿ” which is a normal character you can pass on a > > > shell script if you must, its actual byte-value is 0xFF > > > > Until some helpful application (shell or else) will try to interpret it > > as UTF-8. > > Ehm, how would “some helpful application” manage to get in your qrexec > policy-frameowork? If you fear that you have bigger issues as they could > replace anything with anything... I'm not sure if you've read the QSB carefully. The problem is how the thing executing the service handle arguments. Not policy evaluating part - - there '$' or other potentially shell special characters are handled correctly. Anyone can write a qrexec service, and we want to provide a framework that make it hard to shoot yourself in the foot. > Anyway, to answer your fear. > > No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. > (see attached example file) Or, more likely, it will just switch off utf-8. > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMa8cACgkQ24/THMrX 1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar 338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8 cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg== =mIGj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180220184119.GG2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > The thing you have to rememeber is that the escape character never needs > > to be typed by the user. > > In QRexec you are defining an API, applications like qvm-run are using > > that API. What the user passes into qvm-run and what is actually sent > > to dom0 does not have to be identical. > > In theory yes, but this would introduce more complexity to this code > (taking care where which encoding is used etc). I read the code, there is no encoding. You correctly used the POSIX Portable Character Set for text. So no need for encoding. When you use the qrexec API you just sent a struct with some arrays of bytes for VM names. In your qrexec code you use an array of unsigned chars. Also, no encoding. The point is that you use encodings only when you have **text** with characters > 127. Which you don't allow. The problem you fear doesn't exist. The reason is because when accepting user-input you use encodings. When your app starts talking to qrexec/qubsed there is no longer any encoding. Just an 8-bit bytearray. The text has been standardized. On the 'other' side of qrexec (on dom0) you have perfect control over the situation and you also don't have any need for recoding or encodings or anything like that. It still is just 8 bits data, not encoded. > > I guess you do the translation currently as well; '$' turns into '@' in > > your new code. > > > > The consequence of this is that you don't have to limit yourself to the > > posix list. > > Using the portable characters set for a non-character simply isn't > > needed. > > > > So, knowing that your API is actually based on 8-bit characters and not > > 7 > > bits which you are limiting yourself to, my suggestion is to take > > something above 127 and below 256 as a special char. > > Most fun one would be “ÿ” which is a normal character you can pass on a > > shell script if you must, its actual byte-value is 0xFF > > Until some helpful application (shell or else) will try to interpret it > as UTF-8. Ehm, how would “some helpful application” manage to get in your qrexec policy-frameowork? If you fear that you have bigger issues as they could replace anything with anything... Anyway, to answer your fear. No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. (see attached example file) Or, more likely, it will just switch off utf-8. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/2513384.SI2geNoQLk%40strawberry. For more options, visit https://groups.google.com/d/optout. �b
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, 'Tom Zander' via qubes-devel wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel > wrote: > > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki > wrote: > > > > We've decided to deprecate the '$' character from qrexec-related > > > > usage. > > > > Instead, to denote special tokens, we will use the '@' character, > > > > which we believe is less likely to be interpreted in a special way > > > > by the relevant software. > > > > > > I would argue against the @ sign on account that it is a special > > > character in bash as well. > > > > > > I don't immediately see a way to exploit it, but why risk it? > > > > We absolutely need a special character that is not allowed in qube name to > > make the special tokens immediately obvious in policy. The process I used > > was to list available characters (POSIX Portable Character Set [1]) > [] > > If I missed something, could you please point out? I know shell just good > > enough to know that it's not possible to know every shell quirk. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. In theory yes, but this would introduce more complexity to this code (taking care where which encoding is used etc). > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Until some helpful application (shell or else) will try to interpret it as UTF-8. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMRLUACgkQ24/THMrX 1yxCegf+Iii677oWd0CmJgoygfVfiQnmDl+a7XBX/i+tb8BMqO67AgwzoM6cWXq6 ZaA76a50qKSmcSjj6xSPtg4sPV0hqpgORsnxikAn5zg9vi7QJMJ0q+hKuKVxHAY1 TZSVFynTs6ci0JjgVRiB8QZCrl2eC9hQraGs46u6Zevvj80ZapaEqu0Sh0rowpDe SZ+QbiKi/QD1IeSF03OjnlqtoEyAZtPJ4dMY9F8IpR0P/vzsPxnkx/493HVjSA1i 7Z7kutdCcrGAqCtROhQ9DnS7+GTfdNcDJ5zwZ5yz5fJWlrzFgDSjENuwrSUqU/13 W6HNQVwx/fW+RBseUkJ/o98GHVW8sg== =af4O -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20180220155436.GC2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote: > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote: > > > We've decided to deprecate the '$' character from qrexec-related > > > usage. > > > Instead, to denote special tokens, we will use the '@' character, > > > which we believe is less likely to be interpreted in a special way > > > by the relevant software. > > > > I would argue against the @ sign on account that it is a special > > character in bash as well. > > > > I don't immediately see a way to exploit it, but why risk it? > > We absolutely need a special character that is not allowed in qube name to > make the special tokens immediately obvious in policy. The process I used > was to list available characters (POSIX Portable Character Set [1]) [] > If I missed something, could you please point out? I know shell just good > enough to know that it's not possible to know every shell quirk. :) The thing you have to rememeber is that the escape character never needs to be typed by the user. In QRexec you are defining an API, applications like qvm-run are using that API. What the user passes into qvm-run and what is actually sent to dom0 does not have to be identical. I guess you do the translation currently as well; '$' turns into '@' in your new code. The consequence of this is that you don't have to limit yourself to the posix list. Using the portable characters set for a non-character simply isn't needed. So, knowing that your API is actually based on 8-bit characters and not 7 bits which you are limiting yourself to, my suggestion is to take something above 127 and below 256 as a special char. Most fun one would be “ÿ” which is a normal character you can pass on a shell script if you must, its actual byte-value is 0xFF -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/5355623.KmoKho9gXC%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > We've decided to deprecate the '$' character from qrexec-related usage.
> > Instead, to denote special tokens, we will use the '@' character,
> > which we believe is less likely to be interpreted in a special way
> > by the relevant software.
>
> I would argue against the @ sign on account that it is a special character
> in bash as well.
>
> Search for it here;
> https://linux.die.net/man/1/bash
> I don't immediately see a way to exploit it, but why risk it?
We absolutely need a special character that is not allowed in qube name to
make the special tokens immediately obvious in policy. The process I used was
to list available characters (POSIX Portable Character Set [1]) and substract
the characters that are special to some relevant things:
- - qube name: a-z A-Z 0-9 _ -
- - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
- - POSIX shell reserved words [3]: ! { }
- - non-POSIX things [3]: [ ]
- - special qrexec character: +
- - path separators (POSIX and NT): / \ :
- - regular expressions: ^. (and other already excluded)
This leaves: '\0\a\b,@'. The point is, all characters are special to
something. I'm sure if I searched for more "special" characters, I'd find them
('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
',' we use in other context in policy). So I stopped there and by consensus we
picked '@'.
If I missed something, could you please point out? I know shell just good
enough to know that it's not possible to know every shell quirk. :)
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
[2]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
[3]
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers,| '-.-' |
I fear lack of them.'-._ : ,-'
-- Isaac Asimov `^-^-_>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
/PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
t9joU8uqhcS4Wt6nA9lh
=EN6G
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20180220130403.GL1198%40invisiblethingslab.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote: > We've decided to deprecate the '$' character from qrexec-related usage. > Instead, to denote special tokens, we will use the '@' character, > which we believe is less likely to be interpreted in a special way > by the relevant software. I would argue against the @ sign on account that it is a special character in bash as well. Search for it here; https://linux.die.net/man/1/bash I don't immediately see a way to exploit it, but why risk it? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4514339.zi2rDXN2r4%40strawberry. For more options, visit https://groups.google.com/d/optout.
