Hi,
Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
>
> Current logwatch did change from sending mails with charset iso-8859-1
> to UTF-8. This openes up a potential security hole as UTF-8 is not able
> to display all 8bit data.
Hi Klaus,
Am 2017-01-15 um 17:43 schrieb Klaus Ethgen:
> Hi Willi,
>
> Am Sa den 14. Jan 2017 um 16:43 schrieb Willi Mann:
>> in order to come closer to a fix for this issue, I propose the following
>> two patches:
>
>
>> 0001-Add-outputencoding-parameter.patch
>
>> This patch allows to config
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Willi,
Am Sa den 14. Jan 2017 um 16:43 schrieb Willi Mann:
> in order to come closer to a fix for this issue, I propose the following
> two patches:
>
>
> 0001-Add-outputencoding-parameter.patch
>
> This patch allows to configure the value for
Hi,
Am 2017-01-14 um 16:48 schrieb Mike Tremaine:
>
>> 0002-Use-pager-on-stdout-output-to-terminal.patch
>>
>> Use pager less if output is on terminal. This should address the issues
>> associated with escape sequences in logs that may mess with your
>> terminal. Less seems to be good at filterin
> On Jan 14, 2017, at 7:43 AM, Willi Mann wrote:
>
> Hi,
>
> in order to come closer to a fix for this issue, I propose the following
> two patches:
>
>
> 0001-Add-outputencoding-parameter.patch
>
> This patch allows to configure the value for the charset in the
> Content-Type line in mail o
Hi,
in order to come closer to a fix for this issue, I propose the following
two patches:
0001-Add-outputencoding-parameter.patch
This patch allows to configure the value for the charset in the
Content-Type line in mail output. This should address Klaus Ethgen's
original concern. Since most peo
On Dec/31, Willi Mann wrote:
> I would like to get your input on bug #849531 [1].
> [...]
> So my question is: Is it a security issue if a script sends e-mails
> with encoding=utf-8, but potentially containing invalid utf-8 strings?
> If yes, what would be the (minimum) requirements to address this
h-devel] Bug#849531:
> Possible security problem,new logwatch sends mails with charset UTF-8
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am So den 1. Jan 2017 um 20:24 schrieb Jason Pyeron:
> > Yes, 8-bit ASCII, here is a translation table.
>
> AS
>
> The fail-safe default before was ISO-8859-1. So I suggest to use it
> again.
>
If stream converted output it s require please consider making it a
configurable module in the code base that can be turned on and off and modified
(the module) as needed. Leave the default as is, that way DES
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am So den 1. Jan 2017 um 20:24 schrieb Jason Pyeron:
> Yes, 8-bit ASCII, here is a translation table.
ASCII is 7 bit.
All 8 bit are different encodings.
> > Below 128 it is not a problem as UTF-8 is transparent in this
> > range. But
> > above 1
h-devel] Bug#849531:
> Possible security problem,new logwatch sends mails with charset UTF-8
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am So den 1. Jan 2017 um 17:38 schrieb Jason Pyeron:
> > > What do you want to say with that? Your input is not in UT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am So den 1. Jan 2017 um 17:38 schrieb Jason Pyeron:
> > What do you want to say with that? Your input is not in UTF-8.
>
> That is the point. The OP complaines about ASCII being sent when labeld as
> UTF8, as such it created invalid UTF8 sequence
849531:
> Possible security problem,new logwatch sends mails with charset UTF-8
>
> Hi,
>
> Am 2017-01-01 um 00:20 schrieb Jason Pyeron:
> > Not exactly a valid test, besides it works for me. The
> issue is internal ascii data being written as ascii but
> instructing
Hi,
Am 2017-01-01 um 00:20 schrieb Jason Pyeron:
> Not exactly a valid test, besides it works for me. The issue is internal
> ascii data being written as ascii but instructing consumers
> it is uft8.
>
> $ cat utf8_test.pl
> #!/usr/bin/perl
> #
> use strict;
> use File::Slurp;
>
> my $inputfil
> -Original Message-
> From: Klaus Ethgen
> Sent: Saturday, December 31, 2016 08:48
> To: Willi Mann
> Cc: Jason Pyeron; 849...@bugs.debian.org; logwatch-de...@lists.sourceforge.net
>
> Hi,
>
> Am Sa den 31. Dez 2016 um 14:28 schrieb Willi Mann:
> > thanks for your test cases. However, I
Dear Security Team,
I would like to get your input on bug #849531 [1]. A short summary:
Logwatch is a log summarizer that parses various logfiles and reports a
summary, either via e-mail or to stdout. Parts of the input are copied
verbatim w.r.t. to their encoding to the output (e.g., usernames,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Am Sa den 31. Dez 2016 um 14:28 schrieb Willi Mann:
> thanks for your test cases. However, I don't think that binmode provides
> an acceptable solution, at least not alone. While it ensures that the
> strings are valid utf-8 strings, it will con
pye...@pdinc.us]
>> Sent: Friday, December 30, 2016 14:03
>> To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net
>> Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org;
>> 'Klaus Ethgen'
>> Subject: RE: [Logwatch-devel] Bug#849531
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Fr den 30. Dez 2016 um 22:53 schrieb Jason Pyeron:
> You would have the same issue with cat /var/log/x
True. That is the reason I always tell the people not to use cat for
that. (There is only little you should use cat for ever.)
I seen many
> -Original Message-
> From: Willi Mann
> Sent: Friday, December 30, 2016 16:21
> To: Klaus Ethgen; 849...@bugs.debian.org
> Cc: logwatch-de...@lists.sourceforge.net
> Subject: Re: [Logwatch-devel] Bug#849531: Possible security
> problem, new logwatch sends mai
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
nal Message-
> From: Jason Pyeron [mailto:jpye...@pdinc.us]
> Sent: Friday, December 30, 2016 14:03
> To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net
> Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org;
> 'Klaus Ethgen'
> Subject:
I have opened https://sourceforge.net/p/logwatch/bugs/56/ .
I am working a test case for this right now.
As I see it, there are 3 paths to test.
Output as STDOUT, file, and email. In each case does an 8bit value (0x00..0xff
unsigned) result in a valid UTF-8 character.
Is binmode(STDOUT, ":utf8
Bug#849531: Possible security
> problem, new logwatch sends mails with charset UTF-8
>
> Hi Klaus,
>
> can you elaborate how this could be exploited?
It does not make the list at http://unicode.org/reports/tr36/ , but bad utf-8
**may** cause email programs to behave badly. A google
fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
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 th
Hi Klaus,
can you elaborate how this could be exploited? What would be your
suggested fix?
I'm including the upstream mailing list in the conversation.
thanks you
Willi
Am 2016-12-28 um 10:09 schrieb Klaus Ethgen:
> Package: logwatch
> Version: 7.4.3+git20161207-1
> Severity: critical
>
> Curr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Package: logwatch
Version: 7.4.3+git20161207-1
Severity: critical
Current logwatch did change from sending mails with charset iso-8859-1
to UTF-8. This openes up a potential security hole as UTF-8 is not able
to display all 8bit data.
This is espec
27 matches
Mail list logo