Hi Klaus, Am 2016-12-30 um 18:36 schrieb Klaus Ethgen: > Hi Willi, > > Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann: >> can you elaborate how this could be exploited? > > Well, log principally contains untrusted data that could be injected > from untrusted source. That is no security hole itself. > > But when that data gets displayed with the wrong charset, that can > trigger problems in window managers (for example). See xterm which can > be controlled via ansii sequences. Even more, it could trigger stream > conversion problems if the UTF-8 implementation is not really fully > tested with broken streams.
OK, I understand that text from untrusted sources is dangerous and could be harmful to your terminal - and that it is better to assume logfiles to be such an untrusted source. However, the change only affects mailers, right? For mailers, I would expect them to not trust any mails they get, and therefore to remove any dangerous byte sequences. Otherwise, the mailer contains the security hole - and an attacker does not need to go via logfiles and logwatch, he just sends you mail. When running logwatch such that it writes its output to the terminal, the change does not have any effect on the security, right?. If there is a security issue with untrusted data, it was already there before. So far, I cannot see that the change you mentioned would be problematic. What I do see is that it might be wise to sanitize the output of logwatch. A possible way to go might be to remove any byte with value < 0x20 - unless it is a newline or tab. But that is independent of the ISO-8859-15 to utf-8 change. Bye Willi
