Issue I. User Input Written to Logs

[fpietrosanti]

No description provided.

[fpietrosanti]

All messages should be logged in a way that safely and unambiguously encodes non-printable characters. All logging paths should go through the same, safe sanitizer.

[evilaliv3]

@defuse :

in order to address the issue we have:

• added escape sequence sanitization as suggested in the report; this kind of sanitization is followed both in logfile and terminal logging.
• as in past logfile logging continue to implement also sanitization against the most important chars useful in remote file inclusions attack vectors.
• we have added the unit tests for the filtering function in order to validate the sanitization against both single char sequences and multiple chars sequences: https://github.com/globaleaks/GLBackend/blob/f815d186d1c7bd5c71993ebc79f5fdade1517356/globaleaks/tests/test_utility.py

[defuse]

@evilaliv3 In the code in the report, the return values are prefixed with ': ' or 'binary: ' or 'utf-8: ' so that the result is unambiguous. Those have been removed from the method that was put in globaleaks. I think it is better to be unambiguous, but I'm not sure if it will actually matter in practice. It would certainly help if someone was writing a script to decode the logs.

Other than that it looks good.

[evilaliv3]

thank you @defuse for the fast response. we will evaluate this possibility but i've done it intentionally in order to flatten out all in the same format.

[evilaliv3]

allright also this ticket can be considered closed.

the logs do now filter against terminal escape sequences and not visible characters in general and a complete review of the error messages has been done.

[darius]

Checking the new log_remove_escapes code: it calls str() on the argument, and catches Exception, and in that case returns "Failur in log_remove_escapes %s" % e. If the argument is of a class with str, which raises an exception, and the exception has a str producing something dangerous, then this code fails to escape it. If it used %r instead of %s, I'd be happier, because the normal behavior of %s is a non-escaped string, which the normal result with %r is escaped. It's still possible to override that, but not so likely as an accident.

About the disambiguating prefixes, I'd suggest tailoring them to what's common and nice-looking in your system instead of eliminating them, though like @defuse I'm not sure it'll matter.

[darius]

Alternatively (or, really, in addition), in the failure case I complained about above, you could test the result string for any non-printable ASCII characters, and substitute a last-ditch truly-safe complaint message, if raising an exception is no good. All the other code paths are OK without such a check.

[evilaliv3]

ok for the remediation stage i'm going to simply apply your suggestion for the change from "%s" to "%r". thanks for your review.