Re: what do people think about having sandsifter in debian ?

2018-08-15 Thread Paul Wise
On Thu, Aug 16, 2018 at 8:50 AM, shirish शिरीष wrote:

> First of all thank you for the whole team for keeping Debian as secure
> as the people on the team do to keep Debian free from controversy ( at
> least from the security viewpoint) .

A few clarifications:

debian-security@lists.debian.org is not the contact address for the
Debian Security Team.

The Debian Security Team does not do packaging of security audit tools.

The Debian Security Tools Packaging Team is responsible for that:

https://wiki.debian.org/Teams/pkg-security
https://lists.debian.org/debian-security-tools/

> I just came upon sandsifter today. While I have done an RFP on it ,
> could people have a look at it.

RFPs are not sent anywhere useful by default, you should try to
X-Debbugs-CC the relevant teams if you want others to package
something, or just package it yourself.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: [SECURITY] [DSA 4272-1] linux security update

2018-08-15 Thread Salvatore Bonaccorso
Hi,

On Wed, Aug 15, 2018 at 04:02:59PM +0200, Matus UHLAR - fantomas wrote:
> Hello,
> 
> On 14.08.18 21:52, Salvatore Bonaccorso wrote:
> > CVE-2018-5391 (FragmentSmack)
> > 
> >Juha-Matti Tilli discovered a flaw in the way the Linux kernel
> >handled reassembly of fragmented IPv4 and IPv6 packets. A remote
> >attacker can take advantage of this flaw to trigger time and
> >calculation expensive fragment reassembly algorithms by sending
> >specially crafted packets, leading to remote denial of service.
> > 
> >This is mitigated by reducing the default limits on memory usage
> >for incomplete fragmented packets.  The same mitigation can be
> >achieved without the need to reboot, by setting the sysctls:
> > 
> >net.ipv4.ipfrag_high_thresh = 262144
> >net.ipv6.ip6frag_high_thresh = 262144
> >net.ipv4.ipfrag_low_thresh = 196608
> >net.ipv6.ip6frag_low_thresh = 196608
> 
> It seems that the thresholds should be applied in reverse order, the stretch
> kernel complains if we try to shring the high threshold below the low one
> (and is probably right).

Yes that's right. I have fixed this information/listing in the
webversion of the DSA, but cannot be fixed for the sent mail.
I asked debian-www team if the listing can be improved there.

Regards,
Salvatore



Re: [SECURITY] [DSA 4272-1] linux security update

2018-08-15 Thread Matus UHLAR - fantomas

Hello,

On 14.08.18 21:52, Salvatore Bonaccorso wrote:

CVE-2018-5391 (FragmentSmack)

   Juha-Matti Tilli discovered a flaw in the way the Linux kernel
   handled reassembly of fragmented IPv4 and IPv6 packets. A remote
   attacker can take advantage of this flaw to trigger time and
   calculation expensive fragment reassembly algorithms by sending
   specially crafted packets, leading to remote denial of service.

   This is mitigated by reducing the default limits on memory usage
   for incomplete fragmented packets.  The same mitigation can be
   achieved without the need to reboot, by setting the sysctls:

   net.ipv4.ipfrag_high_thresh = 262144
   net.ipv6.ip6frag_high_thresh = 262144
   net.ipv4.ipfrag_low_thresh = 196608
   net.ipv6.ip6frag_low_thresh = 196608


It seems that the thresholds should be applied in reverse order, the stretch
kernel complains if we try to shring the high threshold below the low one
(and is probably right).


For the stable distribution (stretch), this problem has been fixed in
version 4.9.110-3+deb9u2.


(just a note for those who can't just reboot).

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95



External check

2018-08-15 Thread Security Tracker
CVE-2018-10884: RESERVED
CVE-2018-10917: RESERVED
CVE-2018-12824: RESERVED
CVE-2018-12825: RESERVED
CVE-2018-12826: RESERVED
CVE-2018-12827: RESERVED
CVE-2018-12828: RESERVED
--
The output might be a bit terse, but the above ids are known elsewhere,
check the references in the tracker. The second part indicates the status
of that id in the tracker at the moment the script was run.