Re: amd64 running on Intel Celeron and Pentium?

[Henrique de Moraes Holschuh]

On Sun, 17 Apr 2022, Friedhelm Waitzmann wrote:
> > > You mean, that it is possible to run amd64 on my old hardware

I had quite a lot of trouble mapping this a long time ago for
intel-microcode.  I ended up using several sources including, but not
limited to: ark.intel.com, the processor specification datasheets
available at intel.com, and boot logs.  And ark.intel.com proved to not
be correct at least once from what little I recall.

So, FWIW, according to the work I did at that time:

> > > cpu family  : 6
> > > model   : 22
> > > model name  : Intel(R) Celeron(R) CPU  440  @ 2.00GHz
> > > stepping    : 1

sig 0x10661, 64-bit capable, latest public microcode update: rev 0x43

> > > cpu family  : 15
> > > model   : 2
> > > model name  : Intel(R) Pentium(R) 4 CPU 2.00GHz
> > > stepping    : 4

sig 0xf24, 32-bit only, latest public microcode update: rev 0x20.

-- 
  Henrique Holschuh

Re: Intel Microcode updates

[Henrique de Moraes Holschuh]

On Sun, 23 Jun 2019, Elmar Stellnberger wrote:
> As I read from the latest comments the microcode updates for Core 2 systems
> are officially shipped by Intel via the internet though Intel denies this in

Maybe you should fetch the Intel official release yourself and check it
out yourself.

-- 
  Henrique Holschuh

Re: Intel Microcode updates

[Henrique de Moraes Holschuh]

On Tue, 18 Jun 2019, Elmar Stellnberger wrote:
> Perhaps you could add a bash script that does automatically download the
> microcode like f.i. winetricks does with windows code. That way one could be
> more sure to use the right url for it. I also still have quite a lot of Core
> 2 computers and would thus profit from such a provision.

I can add it as an example, sure, if someone writes one that is good
enough to share and sends it as a *whishlist* bug to the BTS with the
patch.

But I fear it will be pointless.  The README already tells you how to do
it yourself, and people won't read it, why would them find about an
example downloader script?

I have been quite clear enough in my reply below about microcode updates
sourced from random places, so such a downloader would *HAVE* to
download from the official microcode updates distribution, anyway.

> Am 12.06.19 um 16:52 schrieb Henrique de Moraes Holschuh:
> > (BCC'd to #929073 to avoid dragging the BTS into this thread).
> > 
> > On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:
> > > Russell Coker  schrieb:
> > > > Should it be regarded as a bug in the intel-microcode package that it 
> > > > doesn't
> > > > have this update that is "easy enough to source"?  Or do you mean "easy 
> > > > to get
> > > > but not licensed for distribution"?
> > > This is covered by #929073, which links to a PDF by Intel (which documents
> > > that Intel won't ship an update for your CPU).
> > I'd like to add that:
> > 
> > We do not, and will not, distribute in non-free's intel-microcode
> > anything we did not get from Intel (or from someone else who got it from
> > Intel with permission to redistribute).  This ensures all microcode
> > updates we distribute in non-free are under a license that allows
> > redistribution.
> > 
> > Note that, as long as there are very good reasons to do so, I am willing
> > to distribute microcode updates that are no longer being distributed[1],
> > since we did receive it with an appropriate license that allows
> > redistribution in the first place.
> > 
> > Also, one can place whatever microcode updates they got from wherever to
> > /usr/share/misc/intel-microcode*.bin at their own risk and
> > responsibility, and the intel-microcode package will attempt to use it.
> > 
> > [1] as in: "they were being distributed by Intel on the Linux microcode
> > update package in the past, and for more than one release of Intel's
> > microcode update package".

-- 
  Henrique Holschuh

Re: Intel Microcode updates

[Henrique de Moraes Holschuh]

(BCC'd to #929073 to avoid dragging the BTS into this thread).

On Tue, 11 Jun 2019, Moritz Mühlenhoff wrote:
> Russell Coker  schrieb:
> > Should it be regarded as a bug in the intel-microcode package that it 
> > doesn't 
> > have this update that is "easy enough to source"?  Or do you mean "easy to 
> > get 
> > but not licensed for distribution"?
> 
> This is covered by #929073, which links to a PDF by Intel (which documents
> that Intel won't ship an update for your CPU).

I'd like to add that:

We do not, and will not, distribute in non-free's intel-microcode
anything we did not get from Intel (or from someone else who got it from
Intel with permission to redistribute).  This ensures all microcode
updates we distribute in non-free are under a license that allows
redistribution.

Note that, as long as there are very good reasons to do so, I am willing
to distribute microcode updates that are no longer being distributed[1],
since we did receive it with an appropriate license that allows
redistribution in the first place.

Also, one can place whatever microcode updates they got from wherever to
/usr/share/misc/intel-microcode*.bin at their own risk and
responsibility, and the intel-microcode package will attempt to use it.

[1] as in: "they were being distributed by Intel on the Linux microcode
update package in the past, and for more than one release of Intel's
microcode update package".

-- 
  Henrique Holschuh

Re: Intel Microcode updates

[Henrique de Moraes Holschuh]

On Mon, 10 Jun 2019, Russell Coker wrote:
> model name  : Intel(R) Core(TM)2 Quad CPUQ9505  @ 2.83GHz
> 
> On a system with the above CPU running Debian/Testing I get the following 
> results from the spectre-meltdown-checker script.  Is this a bug in the intel-
> microcode package that the latest version isn't packaged?  There is no newer 
> version of intel-microcode in Unstable.

Intel upstream decided to not distribute it, for whatever reason.  The
Core2 will not get any fixes for MDS either (nor will Nehalem and
Westmere).

It is easy enough to source that microcode update if you look for it,
and you can just drop it on /usr/share/misc/intel-microcode.bin with
intel-microcode installed, and update the initramfs.  It will pick the
extra microcode up.

-- 
  Henrique Holschuh

Re: bind9: CVE-2018-5743

[Henrique de Moraes Holschuh]

On Thu, 09 May 2019, Markus Wollny wrote:
> Is there an ETA on the fix for this bind9 vulnerability to be
> available for Debian Stretch yet?

It is already available.

> https://security-tracker.debian.org/tracker/CVE-2018-5743 says that
> the stable branch is still vulnerable (fixed in buster/sid only), even
> though the Debian bug report
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927932 is already
> marked as closed.

Currently, it lists the issue as fixed in the *security* update archive
for stable (stretch-security).   This means the fix has been released to
stable (the current stable is "stretch").

You get timely security updates through the -security archive.

Packages move from -security to stable only on stable point
releases, which happen every 3-5 months, so that we can generate a new
set of install-from-CD/DVD/FLASH images that have up-to-date packages
and drain the -security archive, which is not as extensively mirrored as
the other archives.

Note that the installer will update all packages during the install
process and has the security archives enabled by default.

-- 
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Fri, 04 May 2018, Davide Prina wrote:
> On 04/05/2018 04:06, Paul Wise wrote:
> > On Thu, May 3, 2018 at 4:53 PM, richard lucassen wrote:
> > 
> > > There is also an big increase in time before random is initialized:
> > ...
> > > One of the consequences is that openntpd (or a program like
> > > rdate) hangs until the crng is initialized.
> > 
> > What do these two programs require entropy for?
> 
> security:
> 
> Integrates the latest secure API advances from OpenBSD such as
> getentropy(2), arc4random(3) (a fail-safe CSRNG that works in chroot
> environments), and reallocarray(3) (an integer overflow-checking
> malloc/calloc/realloc replacement).[1]
> 
> you can read more detail on NTP RFC[2]

Well, it is false security if it depends on a RNG with too little
entropy, and unless you have hardware assistance, that also means you
need to delay their start until the RNG is properly seeded.

Maybe we should have a systemd target/sysvinit facility that can be used
properly for "crng available" (and use the !@#$ one for clock sync'd as
well, related to ntp...  dnssec *really* depends on never enabling its
secure mode before you sync'd the clock, for example.  But lots of other
stuff would like to start providing service only after the local clock
has been made realtively accurate by ntp/sntp/whatever).

-- 
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Fri, 12 Jan 2018, Moritz Mühlenhoff wrote:
> Frank Nord  schrieb:
> > Peaking at ubuntu:
> > https://usn.ubuntu.com/usn/usn-3522-3/
> > "USN-3522-1 fixed a vulnerability in the Linux kernel to address
> > Meltdown (CVE-2017-5754). Unfortunately, that update introduced
> > a regression where a few systems failed to boot successfully. This
> > update fixes the problem."
> >
> > Do you know, if the regression mentioned in
> > USN-3522-3 exists in stretch's deb9u2 as of today?
> 
> No, the Ubuntu 4.4 regression was an Ubuntu-specific broken hunk
> in the backported patch sets, it's unrelated to what you're seeing
> in stretch.

For the record, an issue with EFI was found on 4.4 upstream, as well as
another issue with EFI on both 4.4 and 4.9 upstream.  I believe the
fixes will show up in the next -stable.  They are related to the changes
done due to the meltdown mitigation, and they don't trigger on every
system.

-- 
  Henrique Holschuh

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

[Henrique de Moraes Holschuh]

On Thu, 11 Jan 2018, Frank Nord wrote:
> I've problems applying this on my mac mini (Intel(R) Core(TM) 2 Duo CPU,
> P7550  @ 2.6 GHz).

...

> 3.20170707.1~deb9u1 from stretch. What's the recommended
> microcode-version for this kernel?

The one you have is currently fine.  Intel has not published
Spectre-related microcode mitigation for the Core 2 duo, at least not
yet.

Maybe they will update the Core2 duo, maybe they will not... It is a
very old model, the microcode might not have enough control there to do
it without disabling way way too much stuff (and thus incurring an
absurd performance regression).

When the microcode doesn't have the Spectre mitigation support for
whatever reason (or you opt to not use it because it is too slow, etc),
"retpoline" software mitigation should do the job just fine to protect
against the currently known variants of spectre.

However, retpoline support is not ready yet.  It is being worked on the
kernel upstream, and it requires compiler support, too... which is also
being worked at gcc and clang upstream.

We have a couple interesting weeks ahead of us, with lots of -security
and stable updates to do :p

-- 
  Henrique Holschuh

Re: Huge Intel CPU Bug Allegedly Causes Kernel Memory Vulnerability With Up To 30% Performance Hit

[Henrique de Moraes Holschuh]

On Wed, 03 Jan 2018, Vincent Deffontaines wrote:
> It is not fixable by microcode, and requires ugly patching from the kernel
> layer. Other OSes such as Microsoft are concerned as well.

Nobody but Intel knows whether it is fixable in microcode or not for a
given processor family.  And Intel has *NOT* published any public
information about this yet, AFAIK.

Take for example the LAPIC memory sinkhole issue[1], which is quite
dangerous (allows for persistent, stealth ring -2 malware that is
invisible to the BIOS, hypervisor and operating system).  It was widely
discussed, it was officialy acknowledged, and it was touted everywhere
as "impossible to fix" in microcode because it was an architectural
thing.

Well, the LAPIC issue was not just fixable in microcode: it *was indeed
fixed* by a set of microcode updates.  The fixing was done silently(!),
though.  My best guess is that this particular set of updates could not
be issued to the wide public because it *does* change an architectural
behavior, and thus it is supposed to always be deployed along with a
BIOS update to ensure compatibility.  But it is available to vendors,
and at least one vendor of corporate desktops and servers *did* deploy
such firmware updates with the new microcode for systems with processors
as old as the Core2 duo...

Most likely, this new X86_BUG_CPU_INSECURE issue either cannot be fixed
in microcode on every affected processor model (some have more hardwired
paths than others) so you would still need a software-level fix anyway,
or it is just too painful performance-wise to do it in the microcode.

But this, too, is just speculation.  Until Intel document it somewhere
public, I am not assuming it is not possible to fix it with an microcode
update.

[1] http://www8.hp.com/us/en/intel-processor-memory-sinkhole.html

-- 
  Henrique Holschuh

Re: HTTPS enabled Debian Security repository

[Henrique de Moraes Holschuh]

On Fri, 27 Oct 2017, Hans-Christoph Steiner wrote:
> This idea that GPG signatures on the index files is enough has been
> totally disproven.  There was a bug in apt where Debian devices could be
> exploited by feeding them crafted InRelease files:
> 
> https://www.debian.org/security/2016/dsa-3733

This was the *one* bug of this sort in the entire lifetime of apt thus
far, AFAIK.

> If HTTPS was used, that would mean exploiting that would require

One of the dozens of zero-days already found in the TLS stack we had to
run like crazy to patch ?

In fact, the TLS stack is so complex, we can be reasonably sure there is
still at least one remotely-exploitable zero-day there.

Have you ever looked at the library stack in APT's http method, and
compared it with the one in APT's https method?

> HTTPS does not entirely solve all these problems, but it does
> drastically improve things.

That is *not* an opinion shared by everyone, to put it mildly.

-- 
  Henrique Holschuh

Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252

[Henrique de Moraes Holschuh]

On Sat, 17 Dec 2016, Hans-Christoph Steiner wrote:
> One thing that would help a lot with future issues like this is to use
> only encrypted connections in /etc/apt/sources.list.  That can be either
> HTTPS or a Tor Hidden Service .onion address.  For in depth discussion
> of this, see:

You could bootstrap from one of the larger ISO media which have the
entire standard system and you can sha256sum easily, and install without
any networks connected.

Then, manually install the updated .deb packages using an USB pendrive
or something like that.  You can also sha256sum these easily.

Then enable the network, and update the whole system as usual, and run
"tasksel" as root to ask for more package sets, etc.


It is worth notice all this crazy dance is going to become unnecessary
as soon as the next debian stable point release is issued [with an
updated installer image], and new install media are made available.

I will ask the stable release team to consider speeding up the next
Debian stable point-release timeframe based on this.


> https://guardianproject.info/2014/10/16/reducing-metadata-leakage-from-software-updates/

Yeah, right.  However Debian 8 (jessie) and earlier, i.e. the current
Debian stable, runs the apt transports as *root*, and *unjailed*.

For that reason, you do *not* want a complex set of libraries with an
history of being zero-day nurseries anywhere near APT in Debian 8
(jessie) and earlier.  If you enable apt-transport-https in Debian 8 and
earlier, you increase the chances of [eventually] being remote-exploited
a great deal.

So, please go with the bootstrap from an ISO media instead.

NOTE: apt in Debian Stretch (Debian 9), runs the transports as an
unpriviledged user, which is a lot safer.  You should still avoid using
apt-transport-https there unless required, it is much safer to have a
local mirror [properly set up].

-- 
  Henrique Holschuh

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

[Henrique de Moraes Holschuh]

On Wed, Oct 19, 2016, at 20:32, Alexander Schreiber wrote:
> On Wed, Oct 19, 2016 at 12:51:06PM -0200, Henrique de Moraes Holschuh
> wrote:
> > On Tue, Oct 18, 2016, at 18:21, Florian Weimer wrote:
> > > Right.  Debian kernel updates can only be applied with a reboot.  If
> > > we publish a kernel update, its mere availability may put some of our
> > > users out of compliance with their policies, which is why we batch
> > > these updates.
> > 
> > Is this correct?  Really?
> 
> Well, in certain environments I would not be surprised by a security
> policy
> that boils down to: "If a security patch from [authorized source] becomes
> available, it must be applied to all applicable systems within [short
> time]."

I was asking about the kernel team's policy.

I could care less for the policies of "certain environments", they are
NOT likely to be a problem: any remotely sane site with a policy that
enforces a deadline to install security updates (including reboots) will
also have policies on scheduling the required maintenance window for
such updates, *including* what to do when the maintenance window can't
be scheduled to avoid SLA violations.  And that's for environments where
you can't just do staggered updates, taking a set of nodes offline to
update and regression-test, and bring them back to production (or
rollback/abort the update should a regression be detected) without much
(if any) impact to services.

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Re: Vulnerabilities rated medium or low risk may not be fixed by Debian security team, is that correct?

[Henrique de Moraes Holschuh]

On Tue, Oct 18, 2016, at 18:21, Florian Weimer wrote:
> Right.  Debian kernel updates can only be applied with a reboot.  If
> we publish a kernel update, its mere availability may put some of our
> users out of compliance with their policies, which is why we batch
> these updates.

Is this correct?  Really?

-- 
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Wed, Apr 13, 2016, at 02:32, Peter Palfrader wrote:
> On Tue, 12 Apr 2016, Michael Stone wrote:
> 
> > On Tue, Apr 12, 2016 at 08:56:35PM -0300, Henrique de Moraes Holschuh wrote:
> > >Then, maybe we should consider a better way to deal with areas where you
> > >get only one choice out of geoip?
> > 
> > Reach out to the relevant team outlining your issues (e.g., lack of IPv6
> > connectivity)? Advising people to hard code security mirrors isn't the right
> > solution.
> 
> There's also nothing inherently wrong with just having a single address
> in an RRSet.

It means a single point of failure for that region: e.g. if the mirror
is stale, everything in that region will hit the same stale mirror, be
them users using apt, or "unrecommended" leaf mirrors of
debian-security.  This makes it harder for an user to work around the
breakage (they would need to use an unofficial security mirror from a
different region as the backup source for security updates).

Well, it is not a common issue, and it will be even less common if
someone manages to implement the staleness check.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Wed, Apr 13, 2016, at 03:50, Peter Palfrader wrote:
> We can identify at least four causal factors.  Probably more, if we
> look a bit further.
>  (1) The scripts Debian uses to mirror repositories treat the mirroring
>  hierarchy as a tree.  The failure of any node or link will cause
>  the subtrey(s) under the failed component to not receive updates.
>  (2) There is an ongoing network outage between where the australian
>  mirror is and its upstream mirror in the US.
>  (3) The scripts that automatically update the security rotation only
>  check if a server is online and responds to http requests - it
>  does not check if a mirror is current.
>  (4) The nagios warning was missed in all the noise, and the relevant
>  teams are overworked and busy.

Thank you for that information.

If we ever manage to fix (3), this would alleviate most of my worries
over a single mirror being returned in the geo-ip RRSET for some areas
of the Internet.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Wed, Apr 13, 2016, at 05:50, Julien Cristau wrote:
> On Tue, Apr 12, 2016 at 20:29:21 -0300, Henrique de Moraes Holschuh
> wrote:
> > On Tue, Apr 12, 2016, at 16:37, Michael Stone wrote:
> > > On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh
> > > wrote:
> > > >And if you need to access security.debian.org over IPv6, "too bad".
> > > 
> > > Huh?
> > > 
> > > Huh?
> > > 
> > > > host security.debian.org
> > > security.debian.org has address 149.20.20.19
> > > security.debian.org has address 128.61.240.73
> > > security.debian.org has address 128.101.240.215
> > > security.debian.org has address 128.31.0.63
> > > security.debian.org has IPv6 address 2607:ea00:101:3c0b::1deb:215
> > > security.debian.org has IPv6 address 2001:4f8:8:36::1deb:19
> > > security.debian.org has IPv6 address 2610:148:1f10:3::73
> > 
> > Not here. All I get is a single A record.
> > 
> > But that explains a lot more about how full of surprises is that black
> > box than I ever expected. I wonder why I don't get at least one  as
> > well, though.  The mirror it returns has it.
> > 
> I'm guessing "here" means the South America zone?  I've added
> santoro.d.o's ipv6 address to the security.debian.org rotation now, let
> us know if it works out.

Yep, it worked.  Thank you!

host security.debian.org
security.debian.org has address 200.17.202.197
security.debian.org has IPv6 address
2801:82:80ff:8009:e61f:13ff:fe63:8e88

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Tue, Apr 12, 2016, at 16:47, Peter Palfrader wrote:
> On Tue, 12 Apr 2016, Henrique de Moraes Holschuh wrote:
> 
> > We list several mirrors carrying debian security updates in
> > https://www.debian.org/mirror/list-full
> 
> I think we shouldn't.

Well, we do, regardless of whether we should or shouldn't.

And, unless we add an alternate-security.d.o or do something else to
offer a backup access for those that get a single choice out of geoip,
it is probably best to not hide that information IMO.

> > We don't disclose which mirrors are members of the security.debian.org
> 
> https://anonscm.debian.org/cgit/mirror/dsa-auto-dns.git/tree/zones/security.debian.org.zone
> 
> is the file that the security.d.o zone is generated from.

Thanks. That helps.

> > Alternate access URIs for several of the security.debian.org pool
> > members *do* exist, but that information seems not to be clearly
> > displayed anywhere.
> 
> They do?  Anything we actually tell people to use?

Yes, they do. And no, we don't tell people to use them.

It is not any sort of a secret, but since you guys don't want people who
doesn't know better pointing apt to them, I am not naming them here.

> > A good starting point would be to provide a list of official security
> > mirrors (potential members of the security.debian.org pool) that can be
> > accessed directly when geo-ip is directing an user to a pool member that
> > is stale.
> 
> No.  We derotate mirrors regularly for maintenance work.  We don't want
> users to pick their security.d.o mirror.

Then, maybe we should consider a better way to deal with areas where you
get only one choice out of geoip?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Tue, Apr 12, 2016, at 16:37, Michael Stone wrote:
> On Tue, Apr 12, 2016 at 04:19:20PM -0300, Henrique de Moraes Holschuh
> wrote:
> >We don't disclose which mirrors are members of the security.debian.org
> >pool anywhere (that I could find), so we are currently hiding everything
> >behind security.debian.org. This wasn't a problem when a DNS lookup for
> >security.debian.org would return a RR-SET with several A and 
> >records, but geo-ip changed that to return a single A record.  When
> >geo-ip points security.debian.org to a broken or stale mirror for
> >someone, it is a pain to work around it for the duration.
> >
> >And if you need to access security.debian.org over IPv6, "too bad".
> 
> Huh?
> 
> Huh?
> 
> > host security.debian.org
> security.debian.org has address 149.20.20.19
> security.debian.org has address 128.61.240.73
> security.debian.org has address 128.101.240.215
> security.debian.org has address 128.31.0.63
> security.debian.org has IPv6 address 2607:ea00:101:3c0b::1deb:215
> security.debian.org has IPv6 address 2001:4f8:8:36::1deb:19
> security.debian.org has IPv6 address 2610:148:1f10:3::73

Not here. All I get is a single A record.

But that explains a lot more about how full of surprises is that black
box than I ever expected. I wonder why I don't get at least one  as
well, though.  The mirror it returns has it.

Still, I am happy to know our geoip supports IPv6 and will even give you
multiple records if you are somewhere it considers more
connectivity-blessed. Thanks for the good news :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Tue, Apr 12, 2016, at 14:32, Peter Palfrader wrote:
> On Tue, 12 Apr 2016, Henrique de Moraes Holschuh wrote:
> > On Tue, Apr 12, 2016, at 14:06, Adam D. Barratt wrote:
> > > Judging from your e-mail address, I'm going to assume that the answer is 
> > > that security.debian.org resolved to 150.203.164.61.
> > > 
> > > Apparently there was an issue with syncing to that mirror. The sysadmin 
> > > team have triggered a manual sync, so things should be up-to-date now.
> > 
> > Other (leaf ?) .au mirrors also seem to be stale:
> > mirror.aarnet.edu.au, mirror.cse.unsw.edu.au
> > 
> > Either those mirrors are not refreshing at an acceptable rate for
> > something that carries /debian-security, or we have a wider issue than a
> > single .au mirror missing a push.
> > 
> > We don't have leaf (non-push) mirrors in the geo-ip list for
> > security.debian.org, do we?
> 
> We don't support 3rd party security mirrors.  In fact, we actively
> discourage them.  Don't use them.

We list several mirrors carrying debian security updates in
https://www.debian.org/mirror/list-full, but only some of them are
members of the security.debian.org pool, and not every member of the
security.debian.org mirror pool is present in that list either.  The
australian mirror that was stale doesn't appear to be, for example.

We don't disclose which mirrors are members of the security.debian.org
pool anywhere (that I could find), so we are currently hiding everything
behind security.debian.org. This wasn't a problem when a DNS lookup for
security.debian.org would return a RR-SET with several A and 
records, but geo-ip changed that to return a single A record.  When
geo-ip points security.debian.org to a broken or stale mirror for
someone, it is a pain to work around it for the duration.

And if you need to access security.debian.org over IPv6, "too bad".

This clearly is suboptimal.  So, please excuse me if I don't agree that
we actively discourage 3rd party public security mirrors, IMHO we do it
half-heartedly.  And I don't think this is bad either, since it looks
like we don't do that well at providing alternate access to the security
archive either.

Alternate access URIs for several of the security.debian.org pool
members *do* exist, but that information seems not to be clearly
displayed anywhere.

A good starting point would be to provide a list of official security
mirrors (potential members of the security.debian.org pool) that can be
accessed directly when geo-ip is directing an user to a pool member that
is stale. This does mean such mirrors need to expose the security
archive outside of the security.debian.org named vhost, of course.
/debian-security seems to be the preferred pattern, and at least one
push-primary mirror that is a member of the security.debian.org pool
does it that way.

And if that list of official security mirrors that can be accessed
through alternate URIs does exist, I couldn't find it. IMHO that
information needs to be somewhere in
https://www.debian.org/mirror/official, along with whatever strong
recommendations we want to make about it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3547-1] imagemagick security update

[Henrique de Moraes Holschuh]

On Tue, Apr 12, 2016, at 14:06, Adam D. Barratt wrote:
> Judging from your e-mail address, I'm going to assume that the answer is 
> that security.debian.org resolved to 150.203.164.61.
> 
> Apparently there was an issue with syncing to that mirror. The sysadmin 
> team have triggered a manual sync, so things should be up-to-date now.

Other (leaf ?) .au mirrors also seem to be stale:
mirror.aarnet.edu.au, mirror.cse.unsw.edu.au

Either those mirrors are not refreshing at an acceptable rate for
something that carries /debian-security, or we have a wider issue than a
single .au mirror missing a push.

We don't have leaf (non-push) mirrors in the geo-ip list for
security.debian.org, do we?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

ANNOUNCEMENT: AMD processor microcode security update

[Henrique de Moraes Holschuh]

uot;One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh <h...@debian.org>

Re: [SECURITY] [DSA 3224-1] libx11 security update

[Henrique de Moraes Holschuh]

On Sun, Apr 12, 2015, at 15:16, Moritz Muehlenhoff wrote:
 Several other xorg packages (e.g. libxrender) will be recompiled against
 the fixed package after the release of this update. For detailed

The use of bin-NMUs for this is causing utter havock here due to multi-arch:

# dpkg -i /var/cache/apt/archives/libxrender1_1%3a0.9.7-1+deb7u1+b1_*deb
(Reading database ... 398613 files and directories currently installed.)
Preparing to replace libxrender1:amd64 1:0.9.7-1+deb7u1 (using 
.../libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb) ...
Unpacking replacement libxrender1:amd64 ...
dpkg: error processing 
/var/cache/apt/archives/libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb (--install):
 trying to overwrite shared '/usr/share/doc/libxrender1/changelog.Debian.gz', 
which is different from other instances of package libxrender1:amd64
Preparing to replace libxrender1:i386 1:0.9.7-1+deb7u1+b1 (using 
.../libxrender1_1%3a0.9.7-1+deb7u1+b1_i386.deb) ...
De-configuring libxrender1:amd64 ...
Unpacking replacement libxrender1:i386 ...
dpkg: error processing libxrender1:i386 (--install):
 package libxrender1:i386 1:0.9.7-1+deb7u1+b1 cannot be configured because 
libxrender1:amd64 is at a different version (1:0.9.7-1+deb7u1)
dpkg: error processing libxrender1:amd64 (--install):
 package libxrender1:amd64 1:0.9.7-1+deb7u1 cannot be configured because 
libxrender1:i386 is at a different version (1:0.9.7-1+deb7u1+b1)
Errors were encountered while processing:
 /var/cache/apt/archives/libxrender1_1%3a0.9.7-1+deb7u1+b1_amd64.deb
 libxrender1:i386
 libxrender1:amd64

(obviously a straight apt upgrade run or aptitude upgrade run will give similar 
results).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh h...@debian.org


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1428927635.1671226.253003217.078fb...@webmail.messagingengine.com

Re: [SECURITY] [DSA 3121-1] file security update

[Henrique de Moraes Holschuh]

On Fri, 09 Jan 2015, Christoph Biedl wrote:
 Henrique de Moraes Holschuh wrote...
  I do have a private backport of file/5.21+15, but it is a quick hack job
  that dropped multiarch and build-profile support to ease backporting.  If
  someone has a better backport that preserves multiarch support, please
  upload.
 
 file maintainer here. I don't have upload permission for backports, so
 I cannot do the upload. I can and will however prepare one and run my
 extensive regression tests against it. 
 
 If somebody is willing to do the upload part as a long-term
 commitment, please drop me a line.

I can sponsor them, yes.

However, it would be best if we could somehow get you permission to upload
backports of file.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150109192816.ga28...@khazad-dum.debian.net

Re: [SECURITY] [DSA 3121-1] file security update

[Henrique de Moraes Holschuh]

On Thu, 08 Jan 2015, Moritz Muehlenhoff wrote:
 Multiple security issues have been found in file, a tool/library to 

For the record, the file package currently in wheezy-backports is in dire
need of a security update.  It is in fact quite dangerous to run it if you
have it installed together with, e.g., amavisd-new or anything else that
will run file/libmagic on untrusted data from the network.

I do have a private backport of file/5.21+15, but it is a quick hack job
that dropped multiarch and build-profile support to ease backporting.  If
someone has a better backport that preserves multiarch support, please
upload.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150108223758.ga23...@khazad-dum.debian.net

Re: CVE-2014-6277, CVE-2014-6278

[Henrique de Moraes Holschuh]

On Mon, 29 Sep 2014, john wrote:
 So I am confused. I think what I am reading here is that if you applied
 the latest patches to bash [3] you are not vulnerable to CVE-2014-6277.
 CVE-2014-6278. Running the test outlined on Icamtuf.blogspot.co.nz [4]
 seemed to confirm that.

AFAIK, we are still vulnerable to CVE-2014-6277 and CVE-2014-6278, but not
through any interesting attack vectors:  Debian included the RedHat change
that moves the functions to the BASH_FUNC_name() namespace in the DSA-3035
fix.

However, should someone find a way to inject BASH_FUNC_foo()='whatever
triggers these undisclosed bugs' into the environment, the attack is going
to succeed.  To twart that, we have to wait until the embargo is lifted and
the real fix for CVE-2014-6277 and CVE-2014-6278 gets uploaded/published.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140929174102.ga6...@khazad-dum.debian.net

Re: Shellshock: Has CVE-2014-7186 and CVE-2014-7187 been addressed for debian

[Henrique de Moraes Holschuh]

On Sat, 27 Sep 2014, john wrote:
 I was wondering if CVE-2014-7186 and CVE-2014-7187 been addressed yet for
 Debian. I note that Ubuntu pushed another patch addressing these earlier
 today.

Yes, both are addressed by DSA-3035-1.  AFAIK, these CVE numbers were not
yet assigned at the time of the upload, so they were not mentioned in the
changelog.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140928013915.ga30...@khazad-dum.debian.net

Re: [SECURITY] [DSA 3032-1] bash security update

[Henrique de Moraes Holschuh]

On Thu, 25 Sep 2014, Jan Wagner wrote:
 is there still work on CVE-2014-7169, as the fix for CVE-2014-6271
 seems incomplete?

Work on that is ongoing, AFAIK.

AFAIK, exploits for CVE-2014-7169 are already public (one certainly worked
here, with the CVE-2014-6271 patch applied), and there are reports of
ongoing scans (and possibly attacks) for CVE-2014-6271 since at least 12
hours ago.  I didn't see anything about ongoing scans for CVE-2014-7169 yet.

Some of those scans are benign (origin are well known white-hats), some are
not.

I suggest everyone to do a spring cleanup in the login shells for system
accounts, and to deploy mitigation.

BTW: sudo is a viable local attack vector for this vulnerability.

https://news.ycombinator.com/item?id=8365158

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925135438.gd10...@khazad-dum.debian.net

Re: [SECURITY] [DSA 3032-1] bash security update

[Henrique de Moraes Holschuh]

On Thu, 25 Sep 2014, Henrique de Moraes Holschuh wrote:
 BTW: sudo is a viable local attack vector for this vulnerability.

Sort of... turns out it has defenses, which are not immediately obvious to
me how to bypass.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140925150330.ga10...@khazad-dum.debian.net

Re: [SECURITY] [DSA 3027-1] libav security update

[Henrique de Moraes Holschuh]

On Thu, 18 Sep 2014, Paul Wise wrote:
 On Thu, Sep 18, 2014 at 7:30 AM, Bruce Eason wrote:
  YIKES!!
 
  can i help?
 
 The Debian security team can always use some help finding, fixing and
 tracking security issues. Please read the following pages and join our
 IRC channel if you would like to help out.

There is one thing that would be of great value:  We need someone to go over
the debian-backports packages for pending security updates, and notify the
maintainers of the backports or the backports ML.

Currently, at least file and libav are vulnerable in debian-backports.
It is likely that other packages in debian-backports also require updates.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140918120732.ga19...@khazad-dum.debian.net

Re: Debian mirrors and MITM

[Henrique de Moraes Holschuh]

On Fri, 30 May 2014, Erwan David wrote:
 Le 30/05/2014 21:30, Joey Hess a écrit :
  Alfie John wrote:
  Taking a look at the Debian mirror list, I see none serving over HTTPS:
https://www.debian.org/mirror/list
  https://mirrors.kernel.org/debian is the only one I know of.
 
  It would be good to have a few more, because there are situations where
  debootstrap is used without debian-archive-keyring being available, and
  recent versions of debootstrap try to use https in that situation, to at
  least get the weak CA level of security.
 
 Note that at least debian.org DNS is segned by DNSSEC and DANE is used,
 which allows to check that the certificate used by a debian.org site is
 the real one.

We don't ship a DNSSEC-enabled resolver by default, and fixing THAT would
require some very careful considerations and large-scale testing.

That said, AFAIC it is a critical bug on debootstrap that it doesn't just
keel over and die very loudly when run without a trust path to verify the
downloaded packages [as usual, this means we'd need to make it possible to
provide such trust paths for the harder usecases as well].

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140530200202.ga4...@khazad-dum.debian.net

[Debian 6 Squeeze] ANNOUNCEMENT: Intel processor microcode security update

[Henrique de Moraes Holschuh]

THIS ANNOUNCEMENT IS ONLY MEANINGFUL FOR PEOPLE USING DEBIAN 6 (SQUEEZE)
ON COMPUTERS WITH INTEL PROCESSORS.  IT DOES NOT APPLY TO THE MORE RECENT
DEBIAN RELEASES.


A new Intel microcode update is available for Debian 6 (codename Squeeze).

This microcode update is considered a security update.  Users of the newer
versions of Debian (stable/Wheezy, testing/Jessie, unstable) have already
received it.

For technical reasons, Debian 6 (Squeeze) will receive intel-microcode
updates only through squeeze-backports, and only after the same update has
been accepted into Debian stable, and pushed out into a Debian stable point
release.

INSTRUCTIONS ON HOW TO INSTALL THE UPDATE ARE AVAILABLE AT THE LAST PART OF
THIS MESSAGE.

This microcode update release contains fixes for a number of severe issues
on a large number of Intel system processor models produced in the last
five years.  Some of the issues fixed by this update address severe
security risks.

Details about some of the issues fixed by this microcode update, about
microcode updates in general, and about microcode update packages can be
found on previous emails on this thread, at:

https://lists.debian.org/debian-user/2013/09/msg00126.html
https://lists.debian.org/debian-user/2013/09/msg01300.html

Do not expect further announcements about intel-microcode updates, this is
an exception due to the known security nature of this update, and due to
the nonstandard process required to install it for the first time.


Installing the squeeze-backports microcode update:

Manual action by the system administrator is required to enable
squeeze-backports in apt's source.list, and install the backported
intel-microcode and iucode-tool packages for the first time.

After the manual installation of the first update, apt will remember that
it has to get further updates from squeeze-backports.

Please refer to http://backports.debian.org/Instructions/ for general
details on how to use squeeze-backports, and below for step-by-step
simplified instructions.


First install procedure:


1. Enable squeeze-backports in /etc/apt/sources.list, adding:

   deb http://YOURMIRROR.debian.org/debian-backports squeeze-backports main 
contrib non-free

   notice that you need to enable both contrib (for the iucode-tool
   package) and non-free (for the intel-microcode package).

   This is safe.  In Debian's default configuration, squeeze-backports
   packages are only installed by direct request (-t option of apt-get,
   or by explicitly selecting the version from backports in aptitude).

   It will NOT cause your whole system to be updated to squeeze-backports.

2. apt-get update

3. apt-get --purge remove intel-microcode microcode.ctl

4. apt-get -t squeeze-backports install intel-microcode iucode-tool

   (notice that we had to explictly request that packages from
   squeeze-backports were to be used in step 4).


Update procedure:
-

Once installed, packages from squeeze-backports will be handled
automatically when you update the system.  The system remembers which
packages came from squeeze-backports, and looks there for updates.

1. apt-get update
2. apt-get upgrade (or safe-upgrade, or dist-upgrade)

A new microcode update is already available in Debian unstable, and should
make it to squeeze-backports in about four to six months.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140512201833.ga21...@khazad-dum.debian.net

Re: L2TP/IPSec on Mac OSX stop working after openswan upgrade [with patches]

[Henrique de Moraes Holschuh]

On Tue, 29 Apr 2014, Liu DongMiao wrote:
 After checking the patch, I found the it's CVE-2013-6466.patch, it
 removes the compatible code for mac os x and ios, which use a bad
 draft. Now, I have fixed this, and test on mac os x and ios. However,
 I didn't test on other platform, such as linux, windows.

Did you test to make sure you did not reintroduce CVE-2013-6466?  While your
patch is simple, the patch that fixed CVE-2013-6466 is not and touched a lot
of code.  It was not immediately obvious -- at least to me -- that
reenabling the compatibiliy code will still work well after the changes done
to fix CVE-2013-6466.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140501152337.gc2...@khazad-dum.debian.net

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

[Henrique de Moraes Holschuh]

On Sun, 15 Dec 2013, Robert Millan wrote:
  Backporting the fix to these kernels might be a good idea, probably best
  routed through an stable update upload (and not a security upload).
 
 This might be a bit complicated due to significant changes in internal
 APIs. I'm also unsure if the yarrow algorithms used in those versions
 are good enough for the task.
 
 Perhaps we should just disable Via chipset from sys/dev/random/probe.c.
 Would this be a terrible loss for a Technology Preview release?

I don't think it would be a terrible loss.

OTOH, I wouldn't lose any sleep over a VIA PadLock HRNG driving /dev/random
in a tech preview release.

I am not sure VIA ever updated the design with CPRNGs, but the original
one-HRNG and the following two-HRNG designs are very audit-friendly.

Just make sure you give xstore (the new instruction used to read the VIA
PadLock HRNG) a full cacheline worth of buffer (which must also be
cacheline-aligned), due to CPU errata... you'll get memory corruption of
nearby data otherwise.  You also have to audit (or otherwise lock down) the
HRNG configuration, or assume it is operating in its worst mode while
post-processing.  The VIA PadLock RNG *is* a single MSR-write away from
being misconfigured.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131216004912.ga7...@khazad-dum.debian.net

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

[Henrique de Moraes Holschuh]

On Sat, 14 Dec 2013, Steven Chamberlain wrote:
 On 14/12/13 01:08, Henrique de Moraes Holschuh wrote:
  Yeah, I think Linux went through similar blindness braindamage sometime ago,
  but blind trust on rdrand has been fixed for a long time now, and it never
  trusted any of the other HRNGs (or used them for anything at all without a
  trip through rng-tools userspace until v3.12).
 
 I seem to remember that Ted T'so's committed the fix for this only after
 the release of Linux 3.2, so I assuemd wheezy's kernels might be still
 affected?

I'd need to check it througoutly, but almost all important /dev/random
changes in Linux were backported to all stable kernels, and thus eventually
migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of
other backports).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214210047.ga29...@khazad-dum.debian.net

Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)

[Henrique de Moraes Holschuh]

On Sat, 14 Dec 2013, Robert Millan wrote:
 we are going to backtrack and remove RDRAND and Padlock backends and feed
 them into Yarrow instead of delivering their output directly to /dev/random.

Yeah, I think Linux went through similar blindness braindamage sometime ago,
but blind trust on rdrand has been fixed for a long time now, and it never
trusted any of the other HRNGs (or used them for anything at all without a
trip through rng-tools userspace until v3.12).

 Advice from Security Team would be appreciated in order to determine which
 action needs to be taken in Debian.

IMO, Debian kernels ought to never blindly trust RDRAND, or any other HRNG,
for anything related to /dev/random.

Note that the kernel can trust such in-cpu, high-bandwidth/low-latency HRNGs
for other uses that are not related to key material (such as to implement
ASLR).

 kfreebsd 8.3 and 9.0 (wheezy):
   Sets Via chipset to serve /dev/random unconditionally whenever detected,
   but only on i386 (not amd64). Does not support Intel entropy source.
   (see sys/dev/random/probe.c)

Backporting the fix to these kernels might be a good idea, probably best
routed through an stable update upload (and not a security upload).

 kfreebsd 9.2 (jessie / sid):
   Sets Via or Intel chipset to serve /dev/random when detected,
   unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero
   to disable them.

Remove, switch to kfreebsd 10.  Either that, or backport the fix from
kfreebsd 10.

 kfreebsd 10~ (sid):
   All versions in Debian already have the fixed code, which replaces
   random_adaptor_register() with live_entropy_source_register(), thereby
   registering Via and Intel chips as entropy sources to be post
   processed by Yarrow, rather than directly as random adaptors.

Quite acceptable, as it means we'd have the same policy across Linux and
kFreeBSD.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131214010823.gc26...@khazad-dum.debian.net

Re: MIT discovered issue with gcc

[Henrique de Moraes Holschuh]

On Sat, 23 Nov 2013, Michael Tautschnig wrote:
 This should be taken with a grain of salt. (I'm doing research in the area of
 automated software analysis myself.) It clearly is a well-written paper with a
 nice tool. Yet unstable code results from code that would otherwise be
 considered bogus anyway (they give a nice list in Figure 3 in their paper), 
 thus
 it is not necessarily the case that compilers introduce completely new bugs -
 they just might make the existing ones worse. The use of the term
 vulnerabilities could be very misleading here: not all bugs yield security
 issues - many of them might just lead to unexpected behaviour, and not be
 exploitable to gain elevated privileges or the like.

The bugs the paper is about, if I recall correctly, are real code bugs made
dormant by the internal workings of the compiler (often only in some
optimization levels, so the bug might show up at -O0 and not at -O2, for
example).

Obviously these are an issue for Debian.  Not only we'd like to be able to
use c-lang/llvm as a real alternative in the not-too-distant future (say, 3
years from now), and that would likely awaken many of these latent bugs,
but also any major gcc upgrade can also awaken a subset of them.

Whether these dormant bugs will cause information security issues or not
(and most of the wouldn't), they're still a problem.

  This looks very serious indeed, but a quick search of Debian mailing
  lists didn't show anything being acknowledged for this issue should
  Debian users be concerned?

Well, my best guess is that this is going to be considered upstream issues
by the majority of the package maintainers, and thus they won't get much
attention downstream (in Debian) until they start causing large headaches.

So, yes, users should be concerned (but not alarmed).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131124131530.ga3...@khazad-dum.debian.net

Re: Debian APT Key Revocation Procedure

[Henrique de Moraes Holschuh]

On Sun, 03 Nov 2013, Stephen Gran wrote:
 This one time, at band camp, Henrique de Moraes Holschuh said:
  For a more precise answer, please ask the debian-admin ML.
 
 Why?  DSA has nothing to do with this.

Hmm, come to think of it you're correct that they're not the best team to
ask about it.  On second thought, ftp-masters are probably the best team to
ask about this, along with the Debian release team.

Anyway, it looks like it would be best to have the emergency key revocation
and roll-over procedure written down and published to the public.  If it is
already out there, a pointer would be appreciated.

AFAIK, the *regular* key rollovers are handled by a normal update of the
debian-archive-keyring package (extended to stable and old-stable as well),
plus email notification to the debian-announce ML.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131103205250.ga14...@khazad-dum.debian.net

Re: Debian APT Key Revocation Procedure

[Henrique de Moraes Holschuh]

On Thu, 31 Oct 2013, adrelanos wrote:
 But what could you do with the revocation certificate?
 
 Only manually spread the news and ask users to obtain the revocation
 certificate?

We would widely publish that information, that's a given.  But it is not the
only way to publish the revocation certificate and the replacement keys.

 Or will the apt on Debian user's machines somehow learn about that
 revocation certificate? If so, how does that procedure work? Where is it
 configured?

I believe we'd deploy a security update of the debian-archive-keyring
package, with the updated key material and revocation certificates.  There
are backup keys to allow for key rollover.

Now, this does NOT address all scenarios.  It is not a perfect solution.

For a more precise answer, please ask the debian-admin ML.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131101171006.ga1...@khazad-dum.debian.net

ANNOUNCEMENT: Intel processor microcode security update (20130906)

[Henrique de Moraes Holschuh]

A new Intel microcode update (dated 20130906) is available on
unstable, testing and also on wheezy-backports.

A Debian Stable update (through stable-proposed-updates) has been requested,
but it may take some time for it to be approved.  If you cannot wait, please
use the wheezy-backports packages (http://backports.debian.org/).


This microcode update release contains the security update for Embedded
Xeon EC5500/EC3500/LE5500/LE3500 (Nehalem) processors, which Intel left out
of the previous update.  Since this is a security update, I decided it was
worth a note to the mailing lists.

This microcode update release also contains updates for Haswell processors
(4th gen Core i* and Xeon E3-1200v3 processors).  No specific data is known
about the Haswell microcode updates at this time.


Details about microcode updates, and microcode update packages can be found
on previous emails on this thread, which can also be found at:
http://lists.debian.org/debian-user/2013/09/msg00126.html

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130928231337.ga16...@khazad-dum.debian.net

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)

[Henrique de Moraes Holschuh]

On Sun, 08 Sep 2013, Henrik Ahlgren wrote:
  or synaptic to look for new tools, right? Or can we just enable those
  two repositories long enough to load Henrique's tool and the microcode
  updates, then disable them again?
 
 Why do you feel that you even need to ask? You are free to handle the
 situation with your machines in any way you wish. Perhaps just

Indeed.  And if you're not going to use the repositories to get automated
updates, you should at least use the Debian PTS (packages.qa.debian.org) to
track package upload-source events so that you will get an email when the
package is updated.

 Also, it is hard to argue that it is useful to have the ability to fix
 bugs in the CPU without replacing the chip. After all, you will face

Indeed.  Look at the errata lists for the x86 processors of any vendor...

 Does anyone know if the microcode shipped by Intel is always
 encrypted? Their nasty licence prohibits everse engineering,

Yes, it is.  And it is not a half-baked job either.
http://inertiawar.com/microcode/

 decompilation, or disassembly of the blob, but even if you ignored
 that, or even if you had the source code (whatever that means in the
 context of microcode, it is not normal X86 code after all), could you
 make any sense of it without having the whole silicon design
 available?

See here:
http://en.wikipedia.org/wiki/Microcode

You really need a lot of low-level information about the core (and maybe
even the uncore) to do anything useful with the full microcode.

And there is no reason why a microcode update would have the full microcode
inside, either.  It could well be just a patch that only describes changed
sections of the microcode, or even a runtime behaviour change table
(something like a hardware breakpoint + microcode that should run when the
breakpoint is activated, or even a table of internal processor state change
that should be applied when the breakpoint is activated, to fix issues that
are not implemented in microcode).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130908154200.ga5...@khazad-dum.debian.net

Re: Microcode update conundrum (was Re: ANNOUNCEMENT: Intel processor microcode security update)

[Henrique de Moraes Holschuh]

On Sun, 08 Sep 2013, Joel Rees wrote:
 I was hoping that AMD was not going to have the license and
 non-visibility issue that plagues the Intel processor microcode
 updates. But I find this original announcement from when Henrique made
 the updater tool available:
 
 http://lists.debian.org/debian-devel/2012/11/msg00109.html

AMD is better than Intel at telling the general public what a microcode
update fixes.  AMD does publish to the general public the errata each
microcode update fixes.  What each erratum means is also published in the
AMD processor Revision Guides, which are also public.

Not that it will help you much.  Really.  Most of the errata worth fixing
through a microcode update causes either unpredictable system behaviour,
data corruption, or system hangs/reboots.  Only a few fixes are for minor
issues such as power management, performance, or optional features.  And
most of the time, it is very very difficult to access how difficult it is to
hit a given erratum.  So it is a update or else deal, because it always
fixes something horrible (even when the chances of you hitting the issue are
very remote -- but you won't be able to know that, you'll have to update
just in case anyway)

AFAIK, Intel does publish the same kind of information but it is not
available to the general public.  Intel does publish to the general public
the list of errata in their processor specification updates documentation,
it just almost never writes down in public documentation what errata a
microcode update fixes.

And you could also have internal/non-public errata and fixes, nothing forces
Intel, AMD, or any other vendor to disclose (even to their hardware
partners) the full list of errata and behaviour changes (fixes, etc).

Note that even the internal errata/fix information is bound to be really
uninteresting anyway.  Backdoors would not be documented anywhere, heck, it
is very likely that only the one or two engineers that had to implement them
even know about it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130908155505.gb5...@khazad-dum.debian.net

ANNOUNCEMENT: Intel processor microcode security update

[Henrique de Moraes Holschuh]

THIS ANNOUNCEMENT IS ONLY RELEVANT TO SYSTEMS THAT HAVE INTEL
MICROPROCESSORS.

Intel has released a microcode update that fixes at least one severe fault
on every desktop and mobile Intel Core i* and server Intel Xeon system
processor models since (and including) the 1st generation Core-i3/i5/i7 and
Xeon 3500/5500.

Updated microcode packages are available for Debian unstable, Debian
testing, Debian wheezy-backports, and Debian stable-proposed-updates.


== What is a processor microcode update? ==

Microcode is a control sequence/program that implements several internal
functions of the system processor (CPU).

A microcode update can fix many classes of processor defects.  The Linux
kernel can send a microcode update to the processor when one is supplied by
the operating system (Debian).

The microcode update has to be applied every time the processor is reset or
powered off: it doesn't stick.  Therefore, Debian has to install this
microcode update to the initramfs, so as to apply it every time the computer
boots.

Note: the microcode update is applied immediately when you install the
packages, you do not need to reboot.  Howerver, we need to install the
update to the initramfs so that the update will not be _lost_ when you
reboot or power off the computer.


== Installing the Intel microcode update packages ==

Please install the iucode-tool package (from contrib) and the
intel-microcode package (from non-free).

http://packages.debian.org/search?keywords=iucode-tool
http://packages.debian.org/search?keywords=intel-microcode

This will be enough for Debian testing and Debian unstable users, but see
below about multiple kernels.

DEBIAN STABLE USERS NEED TO GET THE UPDATE FROM PROPOSED-UPDATES OR
FROM BACKPORTS, SEE BELOW FOR STABLE UPDATE INSTRUCTIONS.

You must also update the initramfs so that the processor microcode will be
updated after a reboot/power off.  The packages will try to do it
automatically for the running kernel and that should be enough for most
users.

However, if you use several different kernels, please update all the
initramfs images running update-initramfs -k all -u as root.


== Installing updated packages for Debian Stable ==

The updated intel-microcode package will be automatically available to all
Debian Stable users (that enabled contrib and non-free packages) only
after the next Debian Stable point release, which might happen in a couple
weeks.

However, Debian Stable users can receive the updates scheduled for the next
Stable point release early, and that includes this intel-microcode update.

The preferred way to get early stable updates is to configure the package
management system to use the stable-proposed-updates distribution.

To enable the stable-proposed-updates, please read about it here:
http://www.debian.org/releases/proposed-updates.html
https://wiki.debian.org/StableProposedUpdates

Alternatively, you can install the packages manually.  To get the updated
packages directly, please install the current intel-microcode and
iucode-tool packages normally, then download and install the updated
intel-microcode package directly:

 apt-get install iucode-tool intel-microcode

For 64-bit installs, download:
http://http.debian.net/pool/non-free/i/intel-microcode_1.20130808.0+deb7u1_amd64.deb

For 32-bit installs, download:
http://http.debian.net/pool/non-free/i/intel-microcode_1.20130808.0+deb7u1_i386.deb

use dpkg -i to install the correct .deb file. You need to be root.


== Installing the update through backported packages (Linux 3.10+) ==

If you use Debian wheezy/stable *and* also a custom Linux kernel 3.10 or
later, please use the backported packages for enhanced functionality.  You
*must* make sure to enable CONFIG_MICROCODE_EARLY and
CONFIG_MICROCODE_INTEL_EARLY CONFIG_MICROCODE_EARLY when you build the
Linux kernel.

How to enable the backports repository in Debian Wheezy:
http://backports.debian.org/Instructions/

To update/install iucode-tool from backports:
apt-get update
apt-get install -t wheezy-backports iucode-tool intel-microcode amd64-microcode

Updated backports of amd64-microcode were also provided to avoid bad
interactions with intel-microcode.  The up-to-date amd64-microcode package
will be inactive in a system with an Intel processor, and it is very small.


== What do we know about this specific Intel microcode update (20130808)? ==

Intel doesn't publish to the general public much data about microcode
updates, therefore we only have very spotty information about update
20130808, gathered from several sources:

1. It fixes a critical erratum, classified by Intel as a security issue,
that affects any server running 32-bit VMs in PAE mode.

Erratum AAK167/BT248: If a logical processor has EPT (Extended Page
Tables) enabled, is using 32-bit PAE paging, and accesses the
virtual-APIC page then a complex sequence of internal processor
micro-architectural events may cause an incorrect address translation or
machine check on either 

Re: ANNOUNCEMENT: Intel processor microcode security update

[Henrique de Moraes Holschuh]

On Tue, 03 Sep 2013, Paul Wise wrote:
 On Tue, Sep 3, 2013 at 2:05 PM, Henrique de Moraes Holschuh wrote:
  THIS ANNOUNCEMENT IS ONLY RELEVANT TO SYSTEMS THAT HAVE INTEL
  MICROPROCESSORS.
 
 Should this have been sent to debian-security-announce instead?

Well, the security team declined to have the microcode stable update go
through the security queue, therefore I decided it probably did not merit
a non-DSA announcement to debian-security-announce.

Also, I left it cooking on unstable and testing, and later in backports and
proposed-updates for a few days before issuing an announcement just in case
it caused any regressions.

If anyone from the security team feels it would be best to send such an
announcement to d-s-a@l.d.o, please feel free to relay my announcement
there, or drop me a note if you'd rather I send it signed to d-s-a@l.d.o
directly.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130903191846.gc1...@khazad-dum.debian.net

Re: ANNOUNCEMENT: Intel processor microcode security update

[Henrique de Moraes Holschuh]

On Tue, 03 Sep 2013, Henrique de Moraes Holschuh wrote:
 Alternatively, you can install the packages manually.  To get the updated
 packages directly, please install the current intel-microcode and
 iucode-tool packages normally, then download and install the updated
 intel-microcode package directly:
 
  apt-get install iucode-tool intel-microcode
 
 For 64-bit installs, download:
 http://http.debian.net/pool/non-free/i/intel-microcode_1.20130808.0+deb7u1_amd64.deb
 
 For 32-bit installs, download:
 http://http.debian.net/pool/non-free/i/intel-microcode_1.20130808.0+deb7u1_i386.deb
 
 use dpkg -i to install the correct .deb file. You need to be root.

The correct URLs are:

64-bit:
http://http.debian.net/debian/pool/non-free/i/intel-microcode/intel-microcode_1.20130808.0+deb7u1_amd64.deb

32-bit:
http://http.debian.net/debian/pool/non-free/i/intel-microcode/intel-microcode_1.20130808.0+deb7u1_i386.deb

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130903190424.ga1...@khazad-dum.debian.net

Re: Compromising Debian Repositories

[Henrique de Moraes Holschuh]

On Sat, 03 Aug 2013, Volker Birk wrote:
 On Sat, Aug 03, 2013 at 08:46:53PM +1000, Aníbal Monsalve Salazar wrote:
  On Sat, Aug 03, 2013 at 12:17:06PM +0200, Volker Birk wrote:
   Not to mention the build tool chains.
  It reminds me of Ken Thompson's article Reflections on Trusting Trust.
 
 Yes, that's what I'm alluding to. For attacking Debian, being a
 maintainer of say, binutils or gcc would be best. But hey, there are

You'd just go upstream, and attack all distros at once.  It is actually
safer that way.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130803194717.gd10...@khazad-dum.debian.net

Re: how to fix rootkit?

[Henrique de Moraes Holschuh]

On Thu, 09 Feb 2012, Russell Coker wrote:
 There are devices which use firewire to directly access system RAM.  It is 
 also possible to design a PCI/PCIe card which does bus-mastering on external 
 control to dump RAM contents.  I've seen a live demonstration of the use of 

In both cases, an active IOMMU in strict mode should be able to avoid
unrestricted access to system RAM.  The GPU is another nasty piece that can
do a lot of damage, and which you really ought to keep fenced by the IOMMU.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120210012709.gb7...@khazad-dum.debian.net

Re: World writable pid and lock files.

[Henrique de Moraes Holschuh]

On Wed, 11 May 2011, Mike Mestnik wrote:
 On 05/11/11 01:37, helpermn wrote:
  On Tue, 10 May 2011, Henrique de Moraes Holschuh h...@debian.org wrote:
  On Tue, 10 May 2011, helpermn wrote:
  I imagine why files listed below have 666 file mode bits set:
  /var/run/checkers.pid
  /var/run/vrrp.pid
  /var/run/keepalived.pid
  /var/run/starter.pid
  /var/lock/subsys/ipsec
  
 
  You could get the initscripts to send signals to any PID you want, so
  yes, it is a nasty security issue.
 
 
 It should be mandatory for initscripts to verify the pid is indeed an
 instance of there daemon.
 
 ...as well as correcting the world writable bit.

These things are to be fixed properly.  You need to actually create the
pidfile securely in the first place.  Which means using O_CREAT|O_EXCL,
often together with O_CLOEXEC, etc.

Most initscripts will make sure they only signal processes that match the
inode in the path they expect the process to be.  Refer to the --exec option
of start-stop-daemon(8).  However, this cannot be done in any of the more
important daemons where you do not stop-before-upgrading, but rather
restart-after-upgrading.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110511182306.ga27...@khazad-dum.debian.net

Re: World writable pid and lock files.

[Henrique de Moraes Holschuh]

On Tue, 10 May 2011, helpermn wrote:
 I imagine why files listed below have 666 file mode bits set:
 /var/run/checkers.pid
 /var/run/vrrp.pid
 /var/run/keepalived.pid
 /var/run/starter.pid
 /var/lock/subsys/ipsec
 
 Files are created during startup of ipsec (pluto) and keepalived
 deamons.
 
 I think thar leaving them world writable is security hole. For
 example delete or change of its content could confuses monit
 watching them running and restarting when they die.

You could get the initscripts to send signals to any PID you want, so
yes, it is a nasty security issue.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110510141057.ga5...@khazad-dum.debian.net

Re: Squeeze vulnerable to CVE-2010-2943 (xfs+NFS unlinked inode access)

[Henrique de Moraes Holschuh]

On Thu, 17 Feb 2011, dann frazier wrote:
  http://security-tracker.debian.org/tracker/CVE-2010-2943
  It is supposed to be vulnerable.
 
 I've backported a fix for this, but it was too late to make the
 initial release of squeeze. The fix is queued for the first update to
 squeeze, see:
   http://svn.debian.org/wsvn/kernel-sec/active/CVE-2010-2943
 
  Upstream is sitting on backports of this one for some reason, because it is
  not on any stable or longterm kernel as far as I can see.
 
 I forwarded our backport to stable, and it has been tentatively
 accepted for the 2.6.32-longterm tree.

Thank you!

 yes, but note that backport introduced a regression:
   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/692848

Which you took care of.  Again, thank you very much.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110218014502.gb...@khazad-dum.debian.net

Squeeze vulnerable to CVE-2010-2943 (xfs+NFS unlinked inode access)

[Henrique de Moraes Holschuh]

On Wed, 16 Feb 2011, Pascal Hambourg wrote:
 Johan Grönqvist a écrit :
  2011-02-15 22:46, Kelly Dean skrev:
  http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-2943 was
  published Sept 30, 2010, and says that Linux 2.6.32.5 is vulnerable.
  Squeeze uses 2.6.32-5, built on Jan 12, 2011. Is Squeeze's kernel
  fixed, or does it have the vulnerability?

...

  The updates to the 2.6.32 kernel thus seems to be incorporated into the 
  version in squeeze. The page you refer to lists 2.6.32.20 as vulnerable, 
  but no higher versions of 2.6.32, and as 2.6.32.28 appears to be 
  incorporated in squeeze, it seems that squeeze might not be vulnerable.
 
 I do not know if 2.6.32 was vulnerable either, but looking at upstream
 kernel changelogs it seems that the fix was not backported to any
 upstream -stable (now -longterm) release older than 2.6.35, including
 2.6.32. So if upstream 2.6.32 was vulnerable, 2.6.32.28 still is.

http://security-tracker.debian.org/tracker/CVE-2010-2943

It is supposed to be vulnerable.

Upstream is sitting on backports of this one for some reason, because it is
not on any stable or longterm kernel as far as I can see.

RedHat fixed this one:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2943

Ubuntu also did:
http://www.ubuntuupdates.org/packages/show/199704  (Version: 2.6.32-27.49)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110216095916.gc15...@khazad-dum.debian.net

Re: some feedback about security from the user's point of view

[Henrique de Moraes Holschuh]

On Mon, 24 Jan 2011, René Mayrhofer wrote:
 Therefore, I strongly suggest to move away from all uses of MD5 and
 use SHA-2 (=256) instead (SHA1 already makes the crypto community

No. Let's stick to SHA2-256, please.  There are some doubts about how
well sha2-512 holds, it may actually be weaker than sha2-256 against
some attacks (not brute-force, obviously).  It is also faster, and
secure enough for the next three years.  There is no need to waste
resources with sha2-384 and sha2-512 for now.

And, if you're going to be paranoid, you really should check ALL
available hashes (so, if sha1, md5 and sha2-256 hashes are available,
check them all) and fail if any of them fail.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110124152403.ga6...@khazad-dum.debian.net

Re: Question related to FDE (Full Disk Encryption) solution under Linux Debian Lenny

[Henrique de Moraes Holschuh]

On Mon, 24 Jan 2011, Thomas Nguyen Van wrote:
 Our company needs to encrypt hard drives on our machines running under Linux 
 Debian Lenny. 

If you're serious about this, get a real server (HP, IBM, Dell...) with
proper TPM hardware and Linux support.

Then, you'll need to do the (not that easy) work of sealing large ecryptfs
keys using the TPM, probably storing them it on internal solid-state memory
(all these servers have internal slots for either SD or USB solid-state
devices).

You will also want to use trusted-grub, and IMA to make sure you're booting
what you should be booting.  Otherwise, someone could just trojan-horse the
bootstrap and ferry out the keys when they're unsealed.

This is not something Debian suports out-of-the-box, you will have a lot of
homework to do.  But it will be secure.

It is possible that some vendors already have TPM-based support for FDE.
That would be less safe than the above, but it would work out-of-the-box.

The only problem is that you'd have to actually trust the FDE implementation
to not be crap.  Embedded device firmware engineers are, as a rule, used to
nobody outside their small division actually being able to see whatever crap
they're embedding, and to get away with pretty much anything INCLUDING
patent and license violations.  You'd have to be an idiot to trust their
code without further proof.  If the keys are stored _anywhere_ by the HD
firmware, the whole thing would be just snake-oil junk.  It would _not_ be
the first time a HD vendor pulled such a trick (the ATA password-based
security feature is quite worthless on a lot of disks out there).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110124154419.gb6...@khazad-dum.debian.net

Re: Any Account Logs In With Any Password

[Henrique de Moraes Holschuh]

On Mon, 25 Oct 2010, Michael Loftis wrote:
 checks prior to this indicate a soft success.  If you remove
 authentication from your system, its expected that any attempt to
 access will pass, barring and specific denial.

If I remove authentication from my system, I expect it to tell me to get
lost, as that is the _only_ safe failure scenario.  Recovery is supposed to
be done through single-user mode and sulogin in that case (if you don't have
a root window already open somewhere, that is).

This fail-unsafe behaviour looks like it is a feature of the default
config being shipped in /etc/pam.d/common-*.  I wonder what is the
justification behind that decision...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101027210533.gb27...@khazad-dum.debian.net

Re: Any Account Logs In With Any Password

[Henrique de Moraes Holschuh]

On Wed, 27 Oct 2010, Jordon Bedwell wrote:
 On 10/27/2010 04:05 PM, Henrique de Moraes Holschuh wrote:
  On Mon, 25 Oct 2010, Michael Loftis wrote:
  checks prior to this indicate a soft success.  If you remove
  authentication from your system, its expected that any attempt to
  access will pass, barring and specific denial.
  
  If I remove authentication from my system, I expect it to tell me to get
  lost, as that is the _only_ safe failure scenario.  Recovery is supposed to
  be done through single-user mode and sulogin in that case (if you don't have
  a root window already open somewhere, that is).
  
  This fail-unsafe behaviour looks like it is a feature of the default
  config being shipped in /etc/pam.d/common-*.  I wonder what is the
  justification behind that decision...

Hmm, looking at it very carefully, it is not.  common-auth defines pam_deny
as requisite, and pam_permit as required.  This will *always* fail to
autenticate, i.e. it IS failing safe (to a locked state).

So, no, it is not a misfeature of the config being shipped.

Now, if you manage to mess with that pam_deny, then, all hell breaks lose
because the existence of that pam_permit disables libpam's internal
fail-safe.  We would be better off without that pam_permit line at all, if
it is not important for some non-cosmetic reason (which it might well be! I
am wondering what the reason is, however).

But just commenting the pam_unix line should not be able to open the system
wide open.

 Wait, let me get this right.  You have a *server running*, you then
 *remove authentication* on said server and then you *expect* the system

Remove authentication:
You explicitly configure pam to remove authentication.  That means adding a
sufficient pam_permit.so at the right place, which is not something a typo
should cause.

Break authentication:
A typo.

Fail unsafe: system is now wide open.  Security breaches are possible.

Fail safe: system is now locked down for new autentications, already
autenticated sessions keep working (and can be used to repair the system,
for example).  Special procedures can be used to restore normal operation in
the worst case.  No security breach happens because of the failure.

So, yes, it is supposed to fail to locked down state, and the more resilient
it is into failing to locked state when misconfigured (instead of opening
the system to unauthorized access), the better.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101028023005.ge27...@khazad-dum.debian.net

Re: CVE-2009-3555 not addressed in OpenSSL

[Henrique de Moraes Holschuh]

On Wed, 29 Sep 2010, Marsh Ray wrote:
 These five bytes will mean the world to some server admin somewhere,
 who's boss is questioning his judgment for installing Debian
 everywhere and now users are starting to report strange warnings in
 their browsers.

Very well.  Do we have something from OpenSSL upstream, stating that the
patch is safe to apply to the OpenSSL version in Debian stable?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100930025527.ga23...@khazad-dum.debian.net

Re: Cleanup portsentry's iptables rules (WAS: HEAD's UP: possible 0day SSH exploit in the wild)

[Henrique de Moraes Holschuh]

On Mon, 13 Jul 2009, Maik Holtkamp wrote:
 I decided to follow this and on the weekend iptables blocked about 70
 IPs. I am afraid that after some time the box will be DOSed by the
 crowded INPUT chain.

The only _real_ fix for that is to use IPSET (patch for netfilter) to deal
with IPv4, and config portsentry to run a script that just adds IPs to the
proper set you used to block stuff.  You can even add them with a builtin
expire time, so that they get unblocked three days after they were
inserted, or whatever...

I really wish IPSET was merged upstream, but it must be lacking something
fundamental to earn that right (IPv6 support, perhaps?), since it has been
around for a long time now, and it is fully maintained.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

HEAD's UP: possible 0day SSH exploit in the wild

[Henrique de Moraes Holschuh]

As usual, you may want to either raise shields (i.e. disable/restrict access
to the ssh service), or pay extra attention to what is happening on your SSH
inbound gateways...

http://lwn.net/Articles/340360/
http://isc.sans.org/diary.html?storyid=6742
http://secer.org/hacktools/0day-openssh-remote-exploit.html

Yes, it could be a hoax, and I sure hope that's all it is...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Debian suggestion on File Deletion

[Henrique de Moraes Holschuh]

On Mon, 01 Jun 2009, X-No Archive wrote:

 XXMETAXX NAME=XOBOTS CONTENT=NOXNDEX
 x-XX-XXchive: yes

(defanged just in case).

What would exactly this accomplish?  It will go to the WWW mail archives,
but would it contaminate the rest of the pages there and hose spidering for
the WWW mail archives?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Debian suggestion on File Deletion

[Henrique de Moraes Holschuh]

On Mon, 01 Jun 2009, X-No Archive wrote:
 Debian should upgrade its listings software to more modern ones such
 as google or nabble.

I recall we used to honour X-no-archive in the mail *HEADER*, but that was a
_LONG_ time ago, I don't know if we still do.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Why is su preserving the environment?

[Henrique de Moraes Holschuh]

On Sat, 24 Jan 2009, Arthur de Jong wrote:
 On Sat, 2009-01-24 at 11:07 +0100, Josselin Mouette wrote:
  The question is whether we can consider safe to pass authentication
  tokens as environment variables. Either we do, and we fix applications
  that pass environment where they shouldn???t. Either we don???t, and we have
  to find another way to pass them.
 
 You can easily get the environment of a process (of when the process
 started or the actual value depending on the application) by giving ps
 the e option.
 
 It seems this information is from /proc/pid/environ but I don't think
 all *nixes properly protect the environment. So in general I would say
 not to put authentication tokens into the environment.
 
 However, most applications that do something like that put a reference
 to the authentication token in the environment (e.g.
 XAUTHORITY=/tmp/.gdm0QI8NZ) which is ok as long as the access to the
 real token (socket mostly) is protected.

Agreed.  Authentication tokens in the environment have been banned as an
acceptable practice from a security standpoint for a long time, now.
They're immediately visible in way too many systems, and almost always the
environment is considered public anyway and it is not subject to any kind of
auditing, let alone access control...

The other thing you absolutely must not do is to have autentication tokens
anywhere in command lines, for the same reasons.

There are two main safe paths to pass along authentication tokens: by
reference to protected files, or directly through open fds shared by the
processes (only works on parent/children stuff), through private pipes or
sockets.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: What to do about SSH brute force attempts?

[Henrique de Moraes Holschuh]

On Thu, 21 Aug 2008, Michael Tautschnig wrote:
  * use a Firewall to prevent other IP address to connect to your ssh
  service. restrict just to yours (iptables script can be easy to find on
  the web)
 Well, I should have added that my hosts must be world-wide accessible using
 password-based authentication, so this is no option.

In the long term, switch to key-based auth.

 I'm not a huge fan of security by obscurity, so I'd rather stick with 22 for
 now.

Switch to key-based auth.  Brute-forcing the keys is much harder.

Meanwhile, you really should do something to reduce your attack surface, so
fail2ban and the like, plus non-standard ports are a damn good idea while
you implement the proper fix (drop passwords).

 What remains open is what could one do proactively? I don't really feel like
 striking back, but getting rid of the attackers would be kind of nice...

Strike against a botnet?  That's a waste of effort, really, with very few
exceptions.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver

[Henrique de Moraes Holschuh]

On Tue, 08 Jul 2008, Florian Weimer wrote:
 1. Install a local BIND 9 resoler on the host, possibly in
 forward-only mode.  BIND 9 will then use source port randomization
 when sending queries over the network.  (Other caching resolvers can
 be used instead.)
 
 2. Rely on IP address spoofing protection if available.  Successful
 attacks must spoof the address of one of the resolvers, which may not
 be possible if the network is guarded properly against IP spoofing
 attacks (both from internal and external sources).

3. Install lwresd from an updated BIND9, install libnss-lwres, and replace
dns with lwres in /etc/nsswitch.conf.   Make sure to restart lwres when
/etc/resolv.conf changes.

However, expect applications that require DNS round-robin in the resolver to
break (just like they break with the libc resolver with A record ordering
enabled).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions

[Henrique de Moraes Holschuh]

On Wed, 14 May 2008, Micah Anderson wrote:
 authenticity of the server. In other words, ssh sessions are not
 compromised just because an adversary has the host keys (unless a MITM
 is setup, in which case you need bot the host key and the authentication
 key to perform a mitm attack).

Ok.  But I do have one doubt: does the RNG bug affect SSH session IV
generation?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator

[Henrique de Moraes Holschuh]

On Wed, 14 May 2008, Florian Weimer wrote:
  I agree it would be neat if someone with a powerful machine could 
  generate all possible keys. I don't know how long that would take 
  however...
 
 It's not so much a time issue, is a question of storage (or getting that
 data to the OpenSSH server).  A networked service would be feasible, but
 it would also allow some sort of traffic analysis.

I did mean putting a lot of brain grease on it.  Math might shorten the
need for a monstrous lookup table quite a bit, since randomness is not
an issue anymore.   Or it might not.  I am not qualified or skilled on
the math needed for such analysis to really know.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Why not have firewall rules by default?

[Henrique de Moraes Holschuh]

On Wed, 23 Jan 2008, Rolf Kutz wrote:
 On 23/01/08 08:29 -0700, Michael Loftis wrote:
 It's better to leave the service disabled, or even better, completely  
 uninstalled from a security standpoint, and from a DoS standpoint as 
 well. The Linux kernel isn't very efficient at processing firewall 
 rules.  Newer 

 I thought it was very efficient in doing so. YMMV.

Quite the contrary. It is *dog* *slow* for non-trivial firewalls.  You have
to use a number of tricks to optimize the rule walk (many tables, hashing,
etc), and anything that reduces the number of rules (like IPSet) is a major
performance bonus.

Or you can rip the standard netfilter firewall out, and install a
high-performance one (such as HiPAC), but those are mostly unmaintained
these days, and have a lot less features than the standard one.

You need to be doing some *heavy* firewalling (many rules) for any of that
to really matter, and on very fast links (gigabit) because nobody will
notice the firewall's speed on something as a 10Mbit/s link...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Why not have firewall rules by default?

[Henrique de Moraes Holschuh]

On Fri, 25 Jan 2008, Török Edwin wrote:
 If it is 2.6, I suggest you to contact the netfilter mailing list [1],
 and show them your firewall rules,

What makes you think they don't know about this?  It is a design detail of
the way netfilter is implemented, and the two methods of acceleration I
mentioned (ip sets and hipac) are linked in the front page of
www.netfilter.org.

Hashes and other ways of making the packet travel a tree of tables instead
of a single very long one is just an obvious way to optimize it from
userspace.

 with speed measurements on real workload.

There are papers on these, also linked (indirectly, I believe) from
www.netfilter.org.  I have read at least one by the ip set guys, and another
from the hipac guys about one year ago.  I expect the netfilter.org crew
actually *write* such papers when they are bored, there is no way they don't
know about it.  It is a trade-off on code complexity or some such.

And standard netfilter *is* good enough for most uses, plus with the way CPU
power is increasing, it is likely to remain good enough for most uses for
quite a while yet.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Time to replace MD5?

[Henrique de Moraes Holschuh]

On Wed, 13 Jun 2007, Florian Weimer wrote:
  On Tue, 12 Jun 2007, Touko Korpela wrote:
  Debian Security Advisories currently contain MD5 checksums. As MD5 is no 
  longer strong enough, maybe it should be replaced by SHA1 or SHA256?
 
  When combined with size information 
 
 Size information doesn't buy you that much.

When we are talking about a binary blob that matches the *same* md5sum? Yes,
it does.  Causing a MD5 colision with a message of the same size is far more
difficult.

  AND the fact that it needs to be a valid .deb archive, they are
  probably more than strong enough.
 
 That, and the evil twin package would have to be prepared by the
 securty team as well, which isn't a relevant scenario (because they

Would it?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Time to replace MD5?

[Henrique de Moraes Holschuh]

On Tue, 12 Jun 2007, Touko Korpela wrote:
 Debian Security Advisories currently contain MD5 checksums. As MD5 is no 
 longer strong enough, maybe it should be replaced by SHA1 or SHA256?

When combined with size information AND the fact that it needs to be a valid
.deb archive, they are probably more than strong enough.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: debian.org DNSs allow unrestricted zone transfers

[Henrique de Moraes Holschuh]

On Tue, 15 May 2007, Abel Martín wrote:
 I thought zone transfers should only be possible between DNSs which
 have records for the same domain, so why are debian.org DNSs (raff,

Only if you have a reason to hide who is in your domain.

 possibility of suffering DoS attacks (it serves 254 records). Is there
 an explanation for this?

Well, I am not sure about the DoS possibilities, but I take advantage of the
fact that it allows zone tranfers to have a local mirror of @d.o in my bind
resolver.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Remote Root In Nvidia xserver Driver

[Henrique de Moraes Holschuh]

On Wed, 18 Oct 2006, Sam Morris wrote:
  sshing to a compromised machine with X forwarding enabled is already a
  big enough problem without adding root exploits.
  
  Don't ssh with X forwarding to an untrusted machine. Ever.
 
 The point is that I may trust the machine, it may have been compromised

Unfortunately if you cannot know for sure it was not compromised, all you
can do to increase your attack surface is to never ssh with X forwading to
it.

There are alternatives, such as vnc-like systems, which can (in theory) be
made a lot safer than straight X11.

 Isn't the X11 security extension designed to help with these issues? But

Yep, but do you have it set to its strictest modes and declaring all other
connections but the ones from your console as untrusted?  Do you always
use xterm in secure keyboard mode to type in passwords?  I don't know many
people who do either.

 anyway, you can't deny that this vulnerability increases a users' attack
 surface significantly. Especially since someone else pointed out that a

Indeed, it does.

Give nVidia hell over their irresponsible instance on the issue.  Drop
nVidia graphics and start using the latest Intel stuff, or the older ATI
stuff (ATIs that need properietary drivers are even worse than nVidia),
which have non-joke free software support, etc.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: When are security updates effective?

[Henrique de Moraes Holschuh]

On Thu, 31 Aug 2006, Sam Morris wrote:
  You can check with 
  
  # lsof +L1
  
  It will show you open Files that have been
  unlinked. If any of those are part of the upgraded
  packages, you restart that process.
 
 Note that this has been broken since at most Linux 2.6.8. Relying on it
 may cause you to not notice that some processes need to be restarted after
 upgrading a package containing a shared library.
 
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264985

Indeed. lsof +L1 is currently useless for detecting unlinked libraries. 

I've been using lsof | grep path inode to detect them for a while now.
Still, I hope the older, saner lsof +L1 behaviour can be restored soon...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: su - and su - what is the real difference?

[Henrique de Moraes Holschuh]

On Fri, 28 Jul 2006, LeVA wrote:
 What is the difference (I mean in the real world) between running `su` 
 (getting a non-login shell) and `su -` (getting a login shell). Is 

The same that using /bin/su - gains you: a bit more of defence against
someone doing nasty things to your environment.  Note the use of a bit, as
in a small ammount.

If you are going to use - for this reason, do the full thing and run
/bin/su - and not su -.  You don't want to trust $PATH either, after all.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: How to prevent daemons from ever being started?

[Henrique de Moraes Holschuh]

On Mon, 15 May 2006, Emanuele Rocca wrote:
 I don't have an answer for the don't start upon new install problem, 
 though.

I do.  invoke-rc.d support is *mandatory* now in Debian, which means that
for Sid and Etch you can write a policy-rc.d file that forbids starting new
daemons before you configure them.

There are no such scripts packaged yet, although they are quite simple to
write.  See package policyrcd-script-zg2, and the file
/usr/share/doc/sysv-rc/README.policy-rc.d.gz  which is distributed by the
sysv-rc package.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Loïc Minier wrote:
  This is a desktop machine, it should permit sharing of files on your
  local network.  DNS servers have their port 53 open to respond to name

In what planet do you live?  Desktop machines are plugged to extremely
hostile networks all the time (think cable modems).

There is no *should* here, at all.

  Well, no: that's the opposite of plug'n'play.  See, if you're USB stick
  contains a malicious vfat file system, it gets automatically mounted
  nevertheless.  It's a feature.

Not in my servers, it doesn't.  And I should add, not even in my desktops:
all removable filesystems are mounted nodev, nosuid.

Mounting malicious filesystems automatically (vfat can't be one AFAIK, but
it won't bork if you tell it to be nosuid, nodev either) is never a feature,
it is a security hole.

Actually, should we not file security bugs against everything that comes
configured to mount removable filesystems out-of-the box and does so without
specifying nodev, nosuid ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Michael Stone wrote:
 On Fri, Mar 03, 2006 at 10:47:56AM -0300, Henrique de Moraes Holschuh wrote:
 Mounting malicious filesystems automatically (vfat can't be one AFAIK, but
 it won't bork if you tell it to be nosuid, nodev either) is never a 
 feature,
 it is a security hole.
 
 Well, a filesystem can be malicious whether it's mounted nosuid or not. 
 Consider the case of a crafted directory structure that tickles a kernel 
 bug, for example. There's no question that making things easier for 

True.  But that requires a broken kernel, which we patch regularly as a
security procedure anyway.  Mounting removable filesystems suid,dev allow a
lot more damage *by design* in the standard Linux security-model.

So, I repeat my question: should we hunt down and file bugs (grave or worse)
on packages automounting removable media without nosid, nodev ?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Loïc Minier wrote:
  If music sharing is a questionable feature to you, you don't need to
  discuss this further, you're obviously the security guy, talking in
  debian-security@ of stuff he doesn't want to support security-wise, and

You are *not allowed* to support security holes by the Social Contract, on
the grounds that they can cause far more damage to users than whatever
benefits they might bring.  So drop the attitude.  We're trying for a
middle-ground solution, here.

  don't want to see running on his server.  Would this discussion happen
  on a multimedia list, the situation would be kind of the opposite, and
  people would be shouting loud if that wasn't pulled in by default.

Then they can (read: should) use DeMudi, and DeMudi has all the excuses in
the world to ship with all mdns services enabled by default.  The Debian
project *officially* recognizes the need for specialized distributions, you
know.

OTOH, when you package for Debian, you are doing the general distribution
packaging.  You are not allowed to cather to any special group needs in
detriment of security, expect a lot of complaining if you do.

So let's work on a way to reach a middle ground, shall we?  In fact, I think
you already stated in another post that a master switch would be fine, so
this discursion could very well end here and now.

  not having any central server, you have to listen for requests.  Any
  other proposal to implement the functionality and interoperability with
  iTunes is welcome.

The master switch addresses both your needs, and the security ones.  All you
need to do is not to hide it if you're shipping it with the default being
the less secure choice.

IMHO, make it priority medium, use a shared template that all mdns services
can use (there is no reason why we shouldn't generalize this solution), and
you can default to mdns enabled.  Do not use priority low, unless you are
going to default to mdns disabled.

  Besides, the work is done quite cleanly with a chroot and a separate
  user.

Yes, which is good.  But don't feel singled out, we are just as severe with
every package.  A lot of them decided to ship bound to localhost for this
reason.  Others implement master switches through debconf.  Others prefer to
ship with functionality disabled.

As for using a separate user, that is the *rule*, not the exception.  Yes,
some crap in Debian still wants to run as root by default for dubious
reasons, but that's not the rule anymore.

  That's outrageous, the fact you don't have anything on your network is

No, it is not.  Your assumptions are just that, assumptions.  And they may
not be right.

Do not assume you can even *run* an active (as opposed to a passive -
listens only, never transmits) mdns service in a network just because a
package that has mdns capabilities was installed: you cannot know that.

Above all, never ever assume desktops are plugged to trusted networks. That
is, in fact, outrageous.

  I completely agree with the managed network part, but in such a
  network:
  - would you have music players installed?
  - wouldn't you filter out any other port than HTTP, HTTPS, and FTP?

Inside the network?  Most managed networks have filtering at the borders, at
key router nodes, and if it has a more advanced distributed-firewall
mentality, on the all of the important boxes themselves (but that usually
doesn't reach the workstations).

Sure, there are places where the local workstations have remote-controlled
firewalls, but they're not common (and AFAIK rarely used for anything but
emergency virus/worm spread control).

That said, music players are quite often allowed in a lot of managed
networks.  I never worked at a place where they were forbidden, in fact (but
that doesn't mean music *sharing* is allowed).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Loïc Minier wrote:
 On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote:
  True.  But that requires a broken kernel, which we patch regularly as a
  security procedure anyway.  Mounting removable filesystems suid,dev allow a
  lot more damage *by design* in the standard Linux security-model.
 
  And we also support avahi security-wise, and would patch it in the case
  of a knwon vulnerability.

Nobody ever implied that avahi is badly maintained.  And unless mdns/avahi
is somehow being shipped configured in such a way so as to allow for
immediate local root priviledge escalations, I don't think I understood the
point you wanted to make.

I stated that the fact that an hipotetic kernel bug *also* allows for local
root exploits through a nosuid,nodev removable filesystem does *not* excuse
us to have removable filesystems being mounted suid,dev, which depending on
the filesystem type allows for immediate local root privilege escalation,
*by* *design*.

 Current Earth status:   NOT DESTROYED
How fortunate, that ;-)

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Loïc Minier wrote:
 On Fri, Mar 03, 2006, Henrique de Moraes Holschuh wrote:
Well, no: that's the opposite of plug'n'play.  See, if you're USB stick
contains a malicious vfat file system, it gets automatically mounted
nevertheless.  It's a feature.
  Not in my servers, it doesn't.  And I should add, not even in my desktops:
  all removable filesystems are mounted nodev, nosuid.
 
  Oh, and that was certainly the default when you pulled in GNOME?

I have purged GNOME in deference to their lousy practices, so I wouldn't
know.  KDE tried to do that for a while, but it seems to have disabled it
again (or it is buggy).

And I am probably going to raise the issue with the package maintainers as
soon as I have the time to verify the status of all the automounting
packages in Debian, which will take a while.

If their default is suid,dev, that will have to change.

  Actually, should we not file security bugs against everything that comes
  configured to mount removable filesystems out-of-the box and does so without
  specifying nodev, nosuid ?
 
  Think just before that: it's not only the mount options, it's the
  simple mounting which is risky.  It's not music sharing, it's listening
  on the network.

If automounting of removable filesystems is defaulting to enabled, that will
also be an issue to be addressed, sure.

But music sharing isn't designed to allow for local root exploits, is it?
Mounting unix-compatible filesystems in dev,suid modes is.  If you're
worried we are holding mdns apps to a different standard, don't.  It's just
a matter of what is in the radar right now ;-)

I will have to check first if the kernel is taking some extra care, as that
might reduce the number of affected packages.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Fri, 03 Mar 2006, Loïc Minier wrote:
  proposed multiple options in other posts, all of them ignored.  People
  *not* trying for a middle-ground solution are those claiming an open
  port by default is unacceptable, no matter what.

You will notice I didn't propose you disable open ports by default.  What
part of ask it using debconf, priority medium or higher, default can be
enabled tells you do not have open ports for mdns open by default?

don't want to see running on his server.  Would this discussion happen
on a multimedia list, the situation would be kind of the opposite, and
people would be shouting loud if that wasn't pulled in by default.
  Then they can (read: should) use DeMudi, and DeMudi has all the excuses in
  the world to ship with all mdns services enabled by default.  The Debian
  project *officially* recognizes the need for specialized distributions, you
  know.
 
  Or perhaps people wanting total security should create their own distro.

They did, just like the multimedia people.

  Will you push me in reverting any argument you provide in favor of
  security the other way around, or is my point sufficiently clear?

See first paragraph reply.

  Please, bring solutions in this discussion, not arguments, we've got
  enough already.

See first paragraph reply.

  Yep, I proposed multiple solutions already, one of which being a
  debconf-handled setting to start avahi on boot or not (which obviously
  would need to be set to start by default, as for other daemons).

Well, that has more to do with avahi-server than your mdns app. And if you
look for the thread, you will notice I replied to whomever asked that that
avahi-server should start automatically like just every other daemon in
Debian does, that it made sense to bind avahi-server to IPADDR_ANY, and to
use policy-rc.d if you don't want stuff like that hapenning.

But this still does not mean mdns apps should not have the mdns master
switch.  Unless they *need* avahi-server installed and active to even open
a mdns socket, in which case they don't need to implement anything (the
master switch is avahi-server).

  The master switch addresses both your needs, and the security ones.  All you
  need to do is not to hide it if you're shipping it with the default being
  the less secure choice.
 
  I didn't intend to hide it, but it probably won't be high-priority, as
  we both know how this clutters Debian installs.

Leave it at Medium, it is enough.  Avahi mdns isn't high risk (this does not
apply to zeroconf, but I understand that avahi mdns clients and avahi-server
are a different kettle of fish).

  I don't know between priority medium and low.  I should probably look
  at existing debconf-handled settings to get a picture.

Setting it at low defeats the purpose of the question.  The idea is that it
is a *master* switch, no matter how many avahi client apps you install, you
get asked only for the first one.  Since there are (no matter how slight)
security implications, most installs should see it (thus priority medium).

  And here comes localhost again: it's the fourth time someone mentions
  listening to localhost in this discussion, which is quite worthless for
  a publishing / discovery daemon.

It is mentioned as an example that others do *something* to avoid listening
on outside interfaces.  At least to me it is very obvious that in avahi's
case it doesn't make sense to listen on lo only.

You *could*, for a more difficult implementation than the master switch, ask
instead in which interface should avahi servers and clients listen (and
allow for the none reply).  I don't think that's worth the trouble,
however, so I didn't suggest it at first.

  Anyway, I'm not the avahi maintainer, I'm quite sure he would be ok to
  apply a patch providing the relevant debconf-handled settings, would he
  get a bug report requesting this.

That's probably the way to go, as it is much better implemented as a shared
debconf template, and avahi's master packages seem the better place to
document it, at the very least.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Using multicast for security updates

[Henrique de Moraes Holschuh]

On Thu, 23 Feb 2006, Neal Murphy wrote:
 On Thursday 23 February 2006 17:05, Michael Loftis wrote:
  Good idea except this requires large scale rollout of mutlicast, which
  AFAIK, hasn't happened.
 
 I thought it had progressed further than being a curiosity. Is its current 
 scale enough to make a difference?

No, at least not in the Internet.  Multicast file transfers for security
updates could be useful in a large organization, but only if they have slow
WAN links.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: avahi-daemon

[Henrique de Moraes Holschuh]

On Wed, 22 Feb 2006, aliban wrote:
 On debian testing the rhythmbox suggested to install the avahi-daemon that 
 listens on all interfaces by default.

That's on par with the avahi-daemon's idea of how things should happen, and
it makes sense.  Not that I'd want that active in my LAN anyway.

If you don't want services to start before you have manually verified them,
even if you install a package (by accident or whatever), then write an
appropriate policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d) to
do just that.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Security implications of allowing init to re-exec from another path

[Henrique de Moraes Holschuh]

On Wed, 04 Jan 2006, Thomas Hood wrote:
 In #345741 the submitter has requested that /sbin/init be enhanced
 such that it can be re-executed from another path.  The idea is that
 telinit -e INIT_PROG=/path/to/other/init could be done prior to
 telinit u.
 
 Reasons for introducing this feature are given in the discussion of
 #345741.
 
 Obviously not just anyone can do telinit -e.  So it sounds safe.
 
 Nevertheless the sysvinit maintainers thought it would be a good idea
 to ask here whether anyone sees any security problems arising from
 this feature.

Just to make the question a bit more clear for those not reading the bug
report, the real question is, are we causing problems for people who run /
read-only (imagine read-only media) and their security expectations?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: PMASA-2005-6 when register_globals = on

[Henrique de Moraes Holschuh]

On Tue, 15 Nov 2005, Steve Kemp wrote:
 On Tue, Nov 15, 2005 at 05:54:32PM +0100, Piotr Roszatycki wrote:
  http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-6 reports 
  that sarge's phpmyadmin package has a security flaw which is occured only 
  if 
  register_globals = on setting is used.
  
  This feature is disabled in Debian package by default so I doubt if this is 
  serious problem. I'd like to ask if I should prepare the new package for 
  sarge or not?
 
   I think an upload would be justified.

Agreed. I know from real life that many servers are *forced* to run with
register_globals = on, due to reasons I'd rather not comment upon.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Sat, 29 Oct 2005, Thomas Bushnell BSG wrote:
 Because it omits information, crucially, when a particular fact was
 learned.  Why obscure information deliberately?  
 
  That is my whole point of contention.  Not that I'd advocate going over the
  changelog to add and update CAN and CVE data, as the security team already
  said they don't really need it, but I want to know exactly what kind of
  damage one would be doing by updating the changelog like that.  So far, I
  have not been convinced that we should be *against* someone doing it, if he
  has the inclination to do so.
 
 If you add it with the actual date, saying this was fixed by version
 such-and-such or whatever, then you are maintaining a more accurate
 record.  Why deliberately create a less accurate record?

Well, I don't see the purpose for adding dates to minor stuff (which is the
kind of modification I do) as I personaly wouldn't have any use for them
while trying to adopt/debug/NMU a foreign package... but I wouldn't have
anything against adding them, since they're wanted.

I'd still put the updated entries in the changelog past.  IMO they belong
in the proper place in the package timeline.  They'd have a prefix with the
date when they were modified/added, though.  ISO format would be best, I
suppose, as it is quite short and impossible to get confused over
(-mm-dd).

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Fri, 28 Oct 2005, Thomas Bushnell BSG wrote:
 Frans Pop [EMAIL PROTECTED] writes:
  On Thursday 27 October 2005 23:34, Henrique de Moraes Holschuh wrote:
  To me it is a technical matter, as the changelogs are a tool for a
  technical job.
 
  To me, changelogs are primarily a way of informing the user of changes in 
  a package. Including references to fixed security issues is definitely a 
  part of that.
 
 No, this is only one thing.  changelogs are also a record of changes
 made for the sake of the maintainer, and his successors, and other
 members of the project.

Changelogs are by definition a record of the changes made at a given version
of the package.  They cannot be the full story of the package, due to
branching, the story they tell is limited to a signle branch of a package
(unless you want to break the BTS versioning control, anyway).  I am
probably missing how is that definition diferent from a record of changes
made for the sake of the maintainer, and his successors, and other members
of the project.

I stipulate that the changelog is also one of the most useful tools when
passing the batton to someone else, other than a full dump of the VC
repository of the package from the previous maintainer.  I know that from
experience.  And so are them really useful for QA work or even an NMU.  We
probably agree on that, from what you wrote.

Now, please explain to me why a changelog that has had detail added to past
entries so that information that belongs to a given uploaded version IS in
the entry for that version, is worse than one that lacks this information,
OR has that information elsewhere?

That is my whole point of contention.  Not that I'd advocate going over the
changelog to add and update CAN and CVE data, as the security team already
said they don't really need it, but I want to know exactly what kind of
damage one would be doing by updating the changelog like that.  So far, I
have not been convinced that we should be *against* someone doing it, if he
has the inclination to do so.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Fri, 28 Oct 2005, Thomas Bushnell BSG wrote:
 Joey Hess [EMAIL PROTECTED] writes:
  One thing that this bug illustrates pretty well that is quite annoying
  when trying to determine what version of a package actually fixed a
  security hole, is new upstream releases that are listed in the changelog
  as fixing a particular CVE, when the hole was actually fixed in a
  previous debian revision of the old upstream version. That's a case
  where clarity is very useful in the changelog. (So is proper use of the
  new version tracking features of the BTS.)
 
 Seems to me that the right thing to do is:
 
 close the bug with the right version using -done;
 add a *new* changelog entry (not altering the old one), saying bug
 such-and-such was fixed in such-and-such old version.

That is not as good for reference purposes.  It requires that you keep track
of such information while reading the rest of the changelog, should that
information be of any value to you.   It is against the good practices for
technical documentation to do so, except when you have no choice but to use
forward references.

Here's how this issue looks to me:

1. changelogs describe the changes in a **package** over time;

2. changelog entries that fix a past entry by adding/correcting
   data are out of their correct place in the timeline of the **package**
   (and not of the changelog);

3. changelog entries that fix a past entry by adding/correcting data
   are in their correct place in the timeline of the *changelog* (and not
   of the package).

Now, which situation should one care more for, and why?  

I prefer to care more about the package history than about the changelog
itself.  Adding/editing/updating a past entry improves the changelog
description of the package timeline (unless it is a stupid edit that
shouldn't have been done in either way, so let's ignore those).  Why is that
worse than an edit whose only virtue is to keep the *changelog* timeline
intact?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Horms wrote:
 On Wed, Oct 26, 2005 at 11:32:15AM +0200, Thijs Kinkhorst wrote:
  Hello people,
  
  As many of you are probably aware, CVE has changed the naming of their
  id's: the temporary CAN- prefix has been dropped and an id is now
  always of the form CVE--. More information at the CVE website.
  
  I was wondering what to do with changelogs. I think it might make sense
  to rename CAN-... numbers in old entries to CVE-..., since all entries
  have been renamed and this aids to the goal: having one unique string to
  find any vulnerability by.
  
  Are there any thoughts on changing changelogs retroactively? Might it
  even be an idea to add a lintian check for 'old-style' CAN id's?
 
 I believe that changelogs should never be changed restrospectively.

Why not?  Technical reasons only, please.  Fixing changelogs so that they
are more useful in the future is common in Debian.  These are slight edits,
always, not entry suppresion or something like that.  Trimming them down is
also very common on long-standing packages, and something that is needed.
Usually, the older entries are moved to a separate file to rot there
out-of-the-way.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Horms wrote:
   I believe that changelogs should never be changed restrospectively.
  
  Why not?  Technical reasons only, please.  Fixing changelogs so that they
  are more useful in the future is common in Debian.  These are slight edits,
  always, not entry suppresion or something like that.  Trimming them down is
  also very common on long-standing packages, and something that is needed.
  Usually, the older entries are moved to a separate file to rot there
  out-of-the-way.
 
 Because I don't believe in revisionist history, thats all.

That's an extremely weak argument IMO.  I will continue doing what the
security team asks and add CVE numbers to the versions that closed security
bugs, as well as fixing typos and the like when I notice them on my
changelogs.  I do not consider this to be revisionist history.

But at least we know that this subthread can end right here, right now.  It
is useless to discuss beliefs that exist without a technical backing, and I
won't waste my time with it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Thomas Bushnell BSG wrote:
 Henrique de Moraes Holschuh [EMAIL PROTECTED] writes:
  But at least we know that this subthread can end right here, right now.  It
  is useless to discuss beliefs that exist without a technical backing, and I
  won't waste my time with it.
 
 Do you have a technical backing for your view that it is useless to
 discuss beliefs that one?

Parse error: ... that one?  I am sorry, I am not sure I understood what
you mean. IF I got it right, my reply is simple: I will not change my mind
about a technical matter backed by technical reasons, because of the beliefs
of someone else.  Give me technical reasons, and I will listen and I could
be convinced that I am wrong.

Therefore, I will not waste my time with any thread where I ask for
technical reasons and get an ideologic one as a reply.  And I won't waste my
time arguing for the sake of arguing, either.

As for the technical reasons to update and modify past entries in a
changelog, I can name a few without any effort:

  1. Fixing typos do not change the message. If it does, it is not
 a simple typo.  Typos can cause a grep for information to
 fail, thus they are not always harmless.  Typos distract me,
 therefore I fix them on *my* changelogs when I notice them,
 so that they won't distract me ever again.

  2. By properly updating/fixing closes: entries, one can always
 machine-parse the changelog to locate exactly when a bug was 
 fixed. I can use this to feed the new version-aware BTS with
 missing versioning information, for example, if I need/want 
 to.

 Also, by adding the proper closes: entries in the changelog,
 now I have a link to the BTS entry that is related to that
 changelog entry.  This data is extremely useful when you
 are hunting the reasons for a particular change down.

  3. The security team's work is helped by adding the CVE
 information to the proper changelog entry, to the point that
 they have requested everyone to do so.  This requires editing
 past changelog entries quite often.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Joey Hess wrote:
 Henrique de Moraes Holschuh wrote:
3. The security team's work is helped by adding the CVE
   information to the proper changelog entry, to the point that
   they have requested everyone to do so.  This requires editing
   past changelog entries quite often.
 
 I don't think that the security team has ever requested retoractive
 changing of changelogs for CVE entries. I find it hard to envision a

THAT will give me a lot of work to track down.  This was pre BTS-usertags,
and I am not sure if it was from the regular sec. team or the testing sec.
team, and it was a passing comment on a thread.  The requested everyone
might be a bit strong, I suppose, since a post to d-d-a was not made.

Well, I will try to hunt it down but google ain't helping much.

 Although these days I think you'll more likely see the relevant bug in
 the BTS be usertagged with the CVE id before the package is even
 released. Once that tag is there, we're tracking the security issue and
 the changelog entry will only matter to users and other security
 researchers.

Good to know.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Henrique de Moraes Holschuh wrote:
 On Thu, 27 Oct 2005, Joey Hess wrote:
  Henrique de Moraes Holschuh wrote:
 3. The security team's work is helped by adding the CVE
information to the proper changelog entry, to the point that
they have requested everyone to do so.  This requires editing
past changelog entries quite often.
  
  I don't think that the security team has ever requested retoractive
  changing of changelogs for CVE entries. I find it hard to envision a
 
 THAT will give me a lot of work to track down.  This was pre BTS-usertags,

Found it. From: Martin Schulze [EMAIL PROTECTED], Message-ID:
[EMAIL PROTECTED], and Message-ID:
[EMAIL PROTECTED] at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=282681

I was out of line on claiming that the security team asked everyone to add
CAN/CVE numbers to past changelog entries.  There were _two_ requests from
Martin Shulze directed to me, while wearing his security team hat, to change
past entries in a changelog to add CAN/CVE entries, but that's it.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Michael Stone wrote:
 You know, you could have just not posted in the first place. Posting a
 personal opinion about someone else's personal preference and then
 ranting about people wasting your time questioning your personal
 preferences is just flat out stupid.

We all make mistakes.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: CAN to CVE: changing changelogs?

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2005, Frans Pop wrote:
 On Thursday 27 October 2005 22:30, Henrique de Moraes Holschuh wrote:
  When dealing with Debian matters of a technical nature, yes.  When
  dealing with matters outside Debian, or of a non-technical nature, I
  may decide to not take such an instance.  And frankly, as long as it is
  a rule of mine, applied to myself, what business is it of yours?
 
 Problem is that changing historic entries in a changelog is hardly a 
 technical matter.

Hmm, I'd rephrase that to: Is adding detail is the same as changing, when we
are talking about changelogs?

To me it is a technical matter, as the changelogs are a tool for a technical
job.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: SELinux

[Henrique de Moraes Holschuh]

On Wed, 21 Sep 2005, Arvind Autar wrote:
 is no loss  of functionality, why hasn't debian implented SELinux as
 default?

It is not that simple.  We are doing it slowly.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bad press again...

[Henrique de Moraes Holschuh]

On Sat, 27 Aug 2005, Florian Weimer wrote:
 * martin f. krafft:
  I think Alvin was alluding to how it *should* be solved. As in: we
  should have more than one security server, globally spaced.
 
 security.debian.org already is a Single Point of Ownership.  I don't
 think we need multiple ones, so this is definitely a post-etch thing.

Irrelevant if secure apt is deployed correctly.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bad press again...

[Henrique de Moraes Holschuh]

On Sat, 27 Aug 2005, Florian Weimer wrote:
 I don't think so.  Joey seems to be satisfied with this situation, and
 apart from unanswered email messages to [EMAIL PROTECTED], there
 are few complaints, AFAIK.  The email part is very unfortunate indeed,
 but it probably doesn't warrant drastic measures.

Since when increasing the stable security team (i.e. adding more people) is
a drastic measure?

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bad press again...

[Henrique de Moraes Holschuh]

Hi martin!

On Sat, 27 Aug 2005, martin f krafft wrote:

 also sprach Henrique de Moraes Holschuh [EMAIL PROTECTED] [2005.08.27.1540 
 +0200]:
   security.debian.org already is a Single Point of Ownership.  I don't
   think we need multiple ones, so this is definitely a post-etch thing.
  
  Irrelevant if secure apt is deployed correctly.
 
 No. Imagine exim gets a root exploit and I spoof the DNS to some

Yes. Deployed correctly means you require time stamping, and you check it
for undue values. Anyone who can connect to mirrors can connect to SNTP
servers, so what aboud people with bad clocks doesn't hold as an excuse.

No, apt does not have all this functionality yet, but it is not difficult to
add it for etch.

For this to work, you need a master s.d.o mirror, and automatic signing (so
that you can keep the timestamping as low as a few hours).  This gives you a
mirror network, with the same single owning point of failure we have right
now.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bad press again...

[Henrique de Moraes Holschuh]

On Sat, 27 Aug 2005, Henrique de Moraes Holschuh wrote:
 For this to work, you need a master s.d.o mirror, and automatic signing (so
 that you can keep the timestamping as low as a few hours).  This gives you a
 mirror network, with the same single owning point of failure we have right
 now.

Add to it requiring messages to have more than one signature, so that the
sec. team remains the single one point of failure for .deb injection.

The point about secure time keeping is a good one, and the perfect solution
(an authenticated ntp server) ain't doable.  So, we'd have to rely on the
user being capable of keeping his clock accurate and noticing if it is off
by too much with some prompting by apt.  Not a perfect solution at all :(

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Bad press again...

[Henrique de Moraes Holschuh]

On Sat, 27 Aug 2005, Florian Weimer wrote:
 * Henrique de Moraes Holschuh:
  On Sat, 27 Aug 2005, Florian Weimer wrote:
  I don't think so.  Joey seems to be satisfied with this situation, and
  apart from unanswered email messages to [EMAIL PROTECTED], there
  are few complaints, AFAIK.  The email part is very unfortunate indeed,
  but it probably doesn't warrant drastic measures.
 
  Since when increasing the stable security team (i.e. adding more
  people) is a drastic measure?
 
 Correct me if I'm wrong, but the current team doesn't seem to want new
 members.  If you nevertheless force new members upon them, you are in

Huh? They probably do, for all I know. Whether they have people they trust
for the job right now is something else, though.  We can probably expect
that some people will be promoted from the testing security team to the
stable one in a reasonable timeframe (some months) without much fuss.

As for doing it over the current stable security team's wishes, I am not
advocating that AT ALL.  That would be a drastic measure indeed.

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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