Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

[Florian Weimer]

* Christoph Egger:

> Hi!
>
> Steven Chamberlain  writes:
>> tags 706414 + pending
>> thanks
>>
>> I've applied upstream's patch in SVN, I'm running it now on my NFS
>> server and seems okay.
>>
>> Christoph, would you be able to do an upload of this to unstable please?
>
> I'm building right now. As it is too late for wheezy r0 it seems we'll
> need to go through either security or stable-updates for wheezy
> (security Cc-ed and patch attached to get that going).

Thanks.  Can you send a debdiff for an upload targeted at
wheezy-security, and prepare packages (which have to be built
with -sa)?


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ip32aprp@mid.deneb.enyo.de

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

[Florian Weimer]

* Christoph Egger:

> Packages will be in people.d.o:~christoph soon (or shall I upload to
> security directly?

Looks good.  Please upload to security-master directly.  You have to
rebuild with -sa, though, so that the upstream tarball is included in
the upload.


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8738u695l1@mid.deneb.enyo.de

Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

[Florian Weimer]

* Steven Chamberlain:

> On 01/05/13 15:20, Christoph Egger wrote:
>> Florian Weimer  writes:
>>> Looks good.  Please upload to security-master directly.  You have to
>>> rebuild with -sa, though, so that the upstream tarball is included in
>>> the upload.
>> 
>> Should be somewhere in your queue now
>
> Was the upload (src:kfreebsd-9) okay?  Do you need anything further from us?

Sorry for the delay.  I'm taking care of this now.


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fvxeg8eu@mid.deneb.enyo.de

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

[Florian Weimer]

* Steven Chamberlain:

> Hi,
>
> On 22/05/13 19:46, Florian Weimer wrote:
>> Sorry for the delay.  I'm taking care of this now.
>
> Thank you for the DSA.
>
> I notice a problem though when this was (I think - I'm unsure of the
> security team's processes here) copied to the main archive, probably so
> that it can be included in stable-proposed-updates:

Thanks for noticing.

I don't see package in the stable queue:

<http://release.debian.org/proposed-updates/stable.html>

And the dak mirror on ries.debian.org hasn't got it, either.

Could you contact ftpmaster and/or the stable release managers about
this?  I don't think we can do anything about it on the security side.


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871u8w9lkj@mid.deneb.enyo.de

Re: Bug#706414: CVE-2013-3266: Insufficient input validation in the NFS server

[Florian Weimer]

* Adam D. Barratt:

> On Fri, 2013-05-24 at 22:20 +0200, Florian Weimer wrote:
>> * Steven Chamberlain:
>> > I notice a problem though when this was (I think - I'm unsure of the
>> > security team's processes here) copied to the main archive, probably so
>> > that it can be included in stable-proposed-updates:
>> 
>> Thanks for noticing.
> [...]
>> Could you contact ftpmaster and/or the stable release managers about
>> this?  I don't think we can do anything about it on the security side.
>
> We (SRM) can't; we don't have any particular access to the upload
> queues and none to security.d.o.

I still have access to the original .changes files.  If you think that
uploading again would fix things, I can try that.  I'd be surprised if
resolving this were so simple, though. 8-/


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gio84x3@mid.deneb.enyo.de

NetBSD port dead?

[Florian Weimer]

Is the NetBSD port dead?  And if it's not, what's the name of the
kernel packages?  Does the port use GNU libc?

(Please Cc: me on replies as I'm not subscribed to the mailing list.)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: New user - Some problems (emacs, sbcl)

[Florian Weimer]

* Cyril Brulebois:

> About the sbcl package, I never work on bootstrapping, but I'm willing
> to try that soon.

Can SBCL still be compiled with CLISP?  In that case, it's not a real
bootstrapping exercise, and it might be easier to go that route.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbsd package

[Florian Weimer]

* Thorsten Glaser:

> Any progress on the libbsd package, now that licence issues are out
> of the way? IIRC, plans were to get it ready for all arches in lenny?

We need a thread-safe version of something like arc4random as an element
for various security patches (which will target etch).  Shall we
back-port libbsd as a whole, or should we just spin a separate library
package?

I'd also see a change that limits the number of bytes which is read from
/dev/urandom (32 or fewer should be enough).  I'm concerned about
looping shell scripts darinign entropy from the pool at an unacceptably
high rate.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbsd package

[Florian Weimer]

* Thorsten Glaser:

> Florian Weimer dixit:
>
>>I'd also see a change that limits the number of bytes which is read from
>>/dev/urandom (32 or fewer should be enough).  I'm concerned about
>>looping shell scripts darinign entropy from the pool at an unacceptably
>>high rate.
>
> For things like that, the OpenBSD and MirBSD kernels have /dev/arandom,
> which itself is also generated from arc4random(9). It's interesting that
> things like that haven't yet been picked up by other operating systems.

While this is arguably the correct fix (it also addresses the threading
issue), it is not something we can roll out in a security update because
it's unlikely to find its way into upstream kernels.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libbsd package

[Florian Weimer]

* Guillem Jover:

> If the stable release team would be fine with introducing a new source
> package to stable then I guess the easiest is to just "backport".
> I think it most probably should build on etch w/o modifications.
>
> Otherwise from where were you thinking on generating the library
> package?

We need non-predictable PRNGs for DNS transaction IDs and perhaps source
ports (if we can't fix the kernel due to politics) in adns, libc6,
Net::DNS, ldns, and in various DNS proxies and probably some other stuff
I forgot.

The OpenSSL license is incompatbile with some other licenses used by
Debian and cannot be used in a library.  The GNUTLS PRNG drains a lot of
entropy from the pool.  Reading /dev/urandom directly might be another
option, though.

>> I'd also see a change that limits the number of bytes which is read from
>> /dev/urandom (32 or fewer should be enough).  I'm concerned about
>> looping shell scripts darinign entropy from the pool at an unacceptably
>> high rate.
>
> I guess that'd be possible, but on what scenario would you see this
> happening?

Anthing that uses DNS in a loop.  For instance, with a list of a few
dozen URLs,

  while read url ; do wget $url ; done

completely depletes the kernel randomness pool, causing issues for
applications that read from /dev/random.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ZFS on kFreeBSD

[Florian Weimer]

* Jerome Warnier:

> While the current status of Debian GNU/kFreeBSD is interesting, I was
> quite disappointed there is no ZFS support in it (at least any related
> tools).
> Any plans to enable this support?

Is ZFS producton-ready?  On Solaris, Sun recommends to reformat and
restore from backup should your system panic on boot:


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: ZFS on kFreeBSD

[Florian Weimer]

* Florian Weimer:

> * Jerome Warnier:
>
>> While the current status of Debian GNU/kFreeBSD is interesting, I was
>> quite disappointed there is no ZFS support in it (at least any related
>> tools).
>> Any plans to enable this support?
>
> Is ZFS producton-ready?  On Solaris, Sun recommends to reformat and
> restore from backup should your system panic on boot:

Uhm, here's the quote from the FAQ:

| What can I do if ZFS file system panics on every boot?
|
| ZFS is designed to survive arbitrary hardware failures through the
| use of redundancy (mirroring or RAID-Z). Unfortunately, certain
| failures in non-replicated configurations can cause ZFS to panic
| when trying to load the pool. This is a bug, and will be fixed in
| the near future [...]

<http://opensolaris.org/os/community/zfs/faq/#zfspanic>

I don't think we would consider this acceptable for Linux file
systems...


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#559107: weaknesses in BSD PRNG algorithms

[Florian Weimer]

* Petr Salinger:

> If I understand it correctly, the security problem is
> "it allows remote attackers to guess sensitive values such as IP
> fragmentation IDs by observing a sequence of previously generated
> values".
> By default, the next_value is previous_value+1, i.e. unsecure at all.
> It can be enabled to use random (secure) value, the random value is in
> kfreebsd-7 generated by weak X2 algorithm, in kfreebsd-8 by "algorithm
> suggested by Amit Klein".

The state is per-flow.  It's not a global counter, right?

> So the options are:
>
> 1) leave it as is (same as native FreeBSD)
> 2) only backport new algorithm to kfreebsd-7
> 3) change default to use random algorithm in both kfreebsd-7 and kfreebsd-8
> 4) backport new algorithm to kfreebsd-7 and change default to use
>random algorithm in both kfreebsd-7 and kfreebsd-8
>
> What prefers the security team ?

I fear that IPv4 is vulnerable no matter what you do.  If the
guessable state is global, please switch to (4).  A per-flow counter
shouldn't be that problematic.

For IPv6, you should implement (3) or (4) because the 32 bit ID
actually provides some protection against blind spoofing.






-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#567939: No way to display routing table

[Florian Weimer]

Package: freebsd-net-tools
Version: 8.0-2
Severity: important

Both netstat and route fail on squeeze with a 7.2 kernel ("route:
writing to routing socket: Invalid argument" and "netstat: kvm_read:
Bad address").

I think you need to package kernel-specific versions of these tools.



-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#567939: No way to display routing table

[Florian Weimer]

* Axel Beckert:

>> Both netstat and route fail on squeeze with a 7.2 kernel ("route:
>> writing to routing socket: Invalid argument" and "netstat: kvm_read:
>> Bad address").
>> 
>> I think you need to package kernel-specific versions of these tools.
>
> They are there. route is just a (currently too) simple wrapper around
> /lib/freebsd/route to emulate Linux like behaviour. It does not have
> IPv6 support either...

To clarify, I think the problem is that the tools assume a FreeBSD 8.0
kernel, not the FreeBSD 7.2 kernel I've got on my squeeze
installation.


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSO linking changes for wheezy

[Florian Weimer]

* Roland McGrath:

>> I can't see why you think --as-needed is fundamentally wrong or unnecessary.
>
> It is fundamentally wrong because -lfoo means I demand that the
> initializers of libfoo.so run, whether or not I called anything in it.

So it's more like static linking. 8-)

IMHO, the current difference in behavior between dynamic and static
linking is quite odd.  --as-needed changes only one tiny aspect,
unfortunately.


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkt95ciy@mid.deneb.enyo.de

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

> In other words, i don't think a s390x box will ever just die.

I'm sure “death” encompasses all events which might lead Debian to
lose access to relevant hardware.  It's not just about faults with a
piece of equipment.

Re: [Stretch] Status for architecture qualification

[Florian Weimer]

* Lennart Sorensen:

> There are a lot of 32bit powerpc chips still going into embedded systems
> being built today.  They are not going away anytime soon.

Do they implement the ISA required by the existing Debian port?

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Petter Reinholdtsen:

> Something like this should work, I guess:
> 
> if [ ! -f /etc/hostid ]; then
>if [ -e /sys/class/dmi/id/product_uuid ]; then
>sethostidfromuuid $(cat /sys/class/dmi/id/product_uuid)
>else
>   dd if=/dev/urandom bs=1 count=4 of=/etc/hostid 2>/dev/null
>fi
> fi

That's not very different from /etc/machine-id, isn't it?

> We need to figure out how to transform the UUID to a 32 bit integer,
> of course.

And I think this is the crux of the problem.  Whatever we do, with
today's cluster sizes it's just not reliably unique.

You could use /etc/machine-id instead.  Some effort goes into that to
make it actually unique.

DMI data seems risky because it depends on firmware, and there are so
many firmware bugs out there.  It would also not address the matter of
changing host IDs as the result of host migrations.

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Petter Reinholdtsen:

> [Florian Weimer]
>> That's not very different from /etc/machine-id, isn't it?
>
> Ah, thank you very much for bringing this systemd setting to my
> attention.  I was not aware of it.
>
> I agree that it seem very similar in purpose and implementation.  Will
> it be available on non-linux Debian architectures too?

It might be possible to port over this part, yes.

>>> We need to figure out how to transform the UUID to a 32 bit integer,
>>> of course.
>>
>> And I think this is the crux of the problem.  Whatever we do, with
>> today's cluster sizes it's just not reliably unique.
>
> Well, for the set of machines we have available at work (ca. 3000) it
> would be sufficiently unique.

I simulated 100,000 random assigns of 32-bit host IDs to 3,000 hosts,
and got collisions in 104 cases.

For 5,000 hosts, I got 286, and for 10,000, 1,112 (again in 100,000
runs).  I was lazy, it shouldn't be too hard to calculate expected
values accurately.

So a 32-bit value without central coordination is pretty much a time
bomb.

> For most sites it would make the return value from gethostid()
> unique.

The IP address of a host could be better than that.  I doubt it is
possible to imrpove upon the glibc implementation.

>> DMI data seems risky because it depends on firmware, and there are so
>> many firmware bugs out there.
>
> I did not quite understand what you mean here.  Do you mean the DMI
> value in your experience isn't unique?

I wouldn't count on them being unique.  Most such ID fields are
definitely not, and there are groups out there who strongly oppose
device IDs.

Re: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Michael Stone:

> Other platforms have deprecated gethostid, that's the best way forward
> for linux, IMO.

I agree.  It's the most likely outcome if this issue was reported to
glibc upstream.

Re: Bug#595790: [Pkg-zfsonlinux-devel] Bug#595790: hostid: useless unless fixed

[Florian Weimer]

* Richard Laager:

> Getting back to ZFS and /etc/hostid... I would think that a
> randomly-generated /etc/hostid is probably sufficient. Whether that's
> done in the libc, spl, or zfs package makes no difference to me.

As I tried to explain, the risks of collisions without central
coordination looks rather high.  glibc's current approach, using the
IP address associated with the host name, provides a certain level of
coordination, avoiding duplicates.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Niels Thykier:

> armel/armhf:
> 
>
>  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]

Fedora is facing an issue running armhf under virtualization on arm64:

  
  

Unless the discussion has moved somewhere where I can't follow it, no
one seems to have solid idea what is going on.  It's also not clear
that this configuration has substantial vendor or community support.
This makes me concerned that virtualization is a viable path forward
here.

(The discussion on the GCC list started off with a misdirection, sorry
about that.  The brief assumption that this was a hardware quirk is
likely quite wrong.)

>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>in GCC
>(Raised by the GCC maintainer; carried over from stretch)

I'm surprised to read this.  ppc64el features prominently in the
toolchain work I do (though I personally do not work on the GCC side).
>From my point of view, it's absolutely not in the same category as the
MIPS-based architectures.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Riku Voipio:

> On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
>> * Niels Thykier:
>> 
>> > armel/armhf:
>> > 
>> >
>> >  * Undesirable to keep the hardware running beyond 2020.  armhf VM
>> >support uncertain. (DSA)
>> >- Source: [DSA Sprint report]
>> 
>> Fedora is facing an issue running armhf under virtualization on arm64:
>> 
>>   <https://bugzilla.redhat.com/show_bug.cgi?id=1572916>
>
> I think you mean:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1576593

Yes, that's right, I copy-pasted the wrong bug URL.  It's filed as a
Red Hat Enterprise Linux bug because the Fedora builders run Fedora
VMs on that platform.

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Florian Weimer]

* Florian Weimer:

>>  * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this.  ppc64el features prominently in the
> toolchain work I do (though I personally do not work on the GCC side).

The ppc64le situation has been clarified.  It's now listed explicitly
as a primary architecture, as powerpc64le-unknown-linux-gnu:

  <https://gcc.gnu.org/gcc-11/criteria.html>

This has always been the intent, but I can understand that
distributions view powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu quite very different things.