4 ms·

Neither does python. The problem being discussed here is that the format string can access and attribute of the object passed in. From PEP3101 [0]: " Unlike s

Neither does python. The problem being discussed here is that the format string can access and attribute of the object passed in. From PEP3101 [0]: " Unlike some other programming languages, you cannot embed arbitrary expressions in format strings. This is by design - the types of expressions that you can use is deliberately limited. Only two operators are supported: the '.' (getattr) operator, and the '[]' (getitem) operator. The reason for allowing these operators is that they don't normally have side effects in non-pathological code." [0] https://www.python.org/dev/peps/pep-3101/ https://www.python.org/dev/peps/pep-3101/

echelon 10y ago
> Neither does python. I would argue that being able to access any global value is a sufficient enough concern.
- deleted 10y ago
  [deleted]
- zardeh 10y ago
  The security issue here isn't with f strings, which oddly enough, don't have this flaw (because they are literals only). This has to do with new style string formatting, which does not have access to globals.
detaro 10y ago
> don't normally have side effects in non-pathological code so, "be careful with it if you can't make sure code isn't non-pathological or friendly", what the article says.
- gizmo686 10y ago
  The example is not pathalogical. The property that the PEP states is that the expression should not have side effects, which is the case. Having pathological code in this context only elavates the severity from a pure data leak to partial code execution. Of course partial code execution in an unexpected context often leads to arbitrary code execution.
  - geofft 10y ago
    In many webapps, there's a very easy way to go from a data leak to arbitrary code execution. For instance, if you have signed cookies that are pickles of data, the cookie signing key lets you execute arbitrary code (because pickle deserialization can execute arbitrary code).
    - dom0 10y ago
      ... which is why it's a poor idea to do that in the first place, since it has literally a single layer of protection against remote, unauthorized, arbitrary code execution, that depends on keeping a static key secret. Much better idea to use a stupid, non-ACE serialization there.
unscaled 10y ago
Which is still not safe enough, and in effect can be used to access any global variable as described in the OP article. Rust formatting is done by macros - which expand at compile time and accept only string literals. This makes it impossible to pass user input to format!(), println!() and their ilk unless the end-user can access your compiler, in which case you have a much larger problem.
- steveklabnik 10y ago
  There are crates like https://crates.io/crates/strfmt https://crates.io/crates/strfmt which let you accept a non-literal.

echelon 10y ago

> Neither does python. I would argue that being able to access any global value is a sufficient enough concern.

deleted 10y ago
[deleted]
zardeh 10y ago
The security issue here isn't with f strings, which oddly enough, don't have this flaw (because they are literals only). This has to do with new style string formatting, which does not have access to globals.

detaro 10y ago

> don't normally have side effects in non-pathological code so, "be careful with it if you can't make sure code isn't non-pathological or friendly", what the article says.

gizmo686 10y ago
The example is not pathalogical. The property that the PEP states is that the expression should not have side effects, which is the case. Having pathological code in this context only elavates the severity from a pure data leak to partial code execution. Of course partial code execution in an unexpected context often leads to arbitrary code execution.
- geofft 10y ago
  In many webapps, there's a very easy way to go from a data leak to arbitrary code execution. For instance, if you have signed cookies that are pickles of data, the cookie signing key lets you execute arbitrary code (because pickle deserialization can execute arbitrary code).
  - dom0 10y ago
    ... which is why it's a poor idea to do that in the first place, since it has literally a single layer of protection against remote, unauthorized, arbitrary code execution, that depends on keeping a static key secret. Much better idea to use a stupid, non-ACE serialization there.

unscaled 10y ago

Which is still not safe enough, and in effect can be used to access any global variable as described in the OP article. Rust formatting is done by macros - which expand at compile time and accept only string literals. This makes it impossible to pass user input to format!(), println!() and their ilk unless the end-user can access your compiler, in which case you have a much larger problem.

steveklabnik 10y ago
There are crates like https://crates.io/crates/strfmt https://crates.io/crates/strfmt which let you accept a non-literal.