Re: Security support for chromium in jessie

[Michael Gilbert]

On Tue, Aug 15, 2017 at 1:09 PM, Emilio Pozuelo Monfort wrote:
> I think we should do this for as long as it's reasonably possible, given 
> firefox
> updates will get harder and harder (they will require newer versions of rustc,
> which may need to be bootstrapped) so having another supported browser is a 
> good
> idea. So I may looking at this.

It's been a few months now without progress, so the next chromium DSA
will announce that support for jessie is discontinued.

Best wishes,
Mike

Security support for chromium in jessie

[Michael Gilbert]

Hi all,

I do not have enough free time to be able to keep up with security
updates to chromium in jessie (oldstable) any more.  It is technically
feasible to keep it working in a jessie environment, but each update
has been more and more work.  I expect that to continue.

Anyway, if anyone would like to take this on (perhaps the LTS team?)
please do so.  You would need to either be a DD or have a regular
sponsor for it to be practical.  If that doesn't happen within about a
month, I'll announce that security support for chromium in jessie has
been discontinued.

Best wishes,
Mike

Re: Should we be alarmed at our state of security support?

[Michael Gilbert]

John Goerzen wrote:
> You know, Mike, *explicit* in my original email was a question of what
> help is needed.  I was willing to pitch in and help.  I may still be.

If your goal is to help, then that's really cool.

> But how else is someone going to learn that when security-tracker says
> "vulnerable", in hundreds of instances, that may be wrong, other than by
> asking?

By spending the requisite time to get familiar with the thing you're
about to criticize before sounding of a premature alarm.

> To be insulting to someone that asked a polite question about "why does
> debsecan show hundreds of vulnerabilities on an up-to-date system" -- a
> GOOD question -- is frankly astonishing.

The sensationalism was the insult.  If the subject had been more
unsensationalized like, "how can I help?" then I would not have
pressed you with such a critical tone.

In fact Alessandro Ghedini asked just that a few weeks ago, which
started a productive conversation, and within that short time, he is
already editing the tracker, preparing security updates, and releasing
DSAs.

If you want to improve the current state, then that's awesome, but you
need to be willing to volunteer time, learning, and effort to make it
happen.

Criticism without action is bound to be counter-productive.

> Rather than insulting those that might jump in to help, you might send
> links to information on how to pitch in and be of assistance.  Frankly
> if the security team is going to be this prickly, the costs of dealing
> with personalities will eat up too much of my time and drain the
> satisfaction out of doing something useful for me.

Here are some links to get you started:
https://security-tracker.debian.org/tracker/
http://security-team.debian.org/security_tracker.html

If the documentation isn't clear about any particular concern of
yours, then please feel free to improve it or ask questions, and we
can provide answers that can be used to improve it.

Best wishes,
Mike


-- 
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/CANTw=MO_RTnJ3wrg-s4d0NWyOaGxmSvP9S=km+ceqkforqp...@mail.gmail.com

Re: Should we be alarmed at our state of security support?

[Michael Gilbert]

On Wed, Feb 18, 2015 at 9:11 AM, John Goerzen wrote:
> On this machine, it found 472 vulnerabilities.  Quite a few of them fit
> into the remotely exploitable, high urgency category.  Many date back to
> last year, some as far back as 2012.  I've included a few examples at
> the end.

I'm not sure what your approach to counting is, but if it is simply
"debsecan | wc -l" then you are sorely over-counting, not to mention
that vulnerability counting itself is a road to madness:
https://www.blackhat.com/us-13/briefings.html#Martin

On the over-counting topic, since security issues are tracked by
source package, debsecan can show up to 7 different binary packages or
more affected by the same CVE (for example util-linux, krb5).

Also, if you've set up multi-arch, debsecan will show the same CVE
separately for i386 and amd64 (that's a bug by the way).

> Now, it is possible with some of these that the security-tracker
> database ought to be updated to reflect that there is not a true
> vulnerability.  However, many of them seem to be existing issues that
> just got forgotten somehow.  I've traced a few through bug reports and such.

If you follow the secure-testing-commits list for a day, you'll see
the herculean effort the security team puts in to keeping up with the
constant deluge of new and ongoing security issues:
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/secure-testing-commits

So to suggest that not enough is being done is disingenuous and insulting.

> Are we already aware of these issues?

If it's in the security tracker, then of course it is known.

> Do we have plans to fix them?

Of course everything is intended to be fixed, but without a sufficient
number of interested volunteers doing that, how is it supposed to
happen?

> Do we know what would be helpful to fix them?

More volunteers actually doing the hard and constant day to day work
that is security upkeep.  Fewer distracting and obviously
ill-researched blog and mailing list posts would also be nice.

Best wishes,
Mike


-- 
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/CANTw=mothu8uhqcw75agy110sxm8c5jjpeznbesugsmytqu...@mail.gmail.com

Re: Missing tiff3 patch in security repo

[Michael Gilbert]

On Wed, Feb 18, 2015 at 12:50 PM, John Goerzen wrote:
>> [wheezy] - tiff3  (the changes that [a]ffect the library are just
>> hardening, converting uses of sprintf to snprintf. those can be rolled
>> into the next tiff3 update, but a separate dsa isn't needed)
>>
>>
> I saw that too, though the bug report says something different, the DSA
> note is probably correct.  But then why is wheezy listed as vulnerable?
>
> Do they think that sprintf is safe?

The patch for CVE-2013-1961 is right there attached to my nmu message
in #706674.  Please feel free to wheezy-pu tiff3 if the lack of
snprintf hardening there really bothers you.

Best wishes,
Mike


-- 
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/CANTw=MM_jw+nr6HPC6mY-xEnLej7dn7t8B_x6v86=mdpacv...@mail.gmail.com

Re: Security EOL within Debian Stable

[Michael Gilbert]

On Wed, Feb 4, 2015 at 8:09 PM, Stephen Dowdy wrote:
> So, if a user installs said package, but fails to notice any EOL DSA
> on it, the package gets left in place in a potentially VULNERABLE
> state.  I.E. if a known exploit comes out, and the package is still
> installed, the end-user could get a nasty surprise thinking that
> because they've added security support to apt-sources and regularly
> update, that they are protected.   This is a non-optimal and undesired
> end-result.

The debian-security-support package somewhat addresses those concerns
[0], but it is not currently installed by default.  There was some
discussion to make that happen, but hasn't been followed through.

> Note that chromium is in 'main' -- not 'contrib' or ..., so there's a
> valid expectation that its security support won't just silently stop
> -- unlike the other FAQ entry that says there's basically no security
> support or contrib, non-free..

I'm not sure where you get the "silently" concern from, but this topic
is already discussed in wheezy's release notes [1].  The problem with
that of course you'll point out is that users often don't read that...

Best wishes,
Mike

[0] https://packages.qa.debian.org/d/debian-security-support.html
[1] 
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security


-- 
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/CANTw=MORX_fRMNiz5N0eVT_cXEp43a3JaD=17KO5zPAiGsP0=q...@mail.gmail.com

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Michael Gilbert]

On Wed, Feb 4, 2015 at 3:38 PM, Paul van der Vlis wrote:
>> The backports team expects backporters to have demonstrated competence
>> with the packages that they're planning to upload.  Anyone considering
>> this should first get involved with the package maintenance teams
>> first and help with a few unstable uploads.
>
> I understand. Good thing. But maybe the normal packagers could think
> about a backport.

For chromium, that's me, but it's not an interest of mine.  If it's
going to happen, it will require a motivated volunteer with the itch
to do the work.

> In the past, Iceweasel and Icedove never had a year security support
> after a new release. Maybe there where other reasons to stop the
> support, but I think this should be seen as a problem/bug.

It's a lot of work maintaining web browsers.  When the next stable
release comes out, that work doubles, so it is far more practical only
to support the newer one.

> In my opinion Iceweasel, Chromium, etc, don't belong in "main", they
> belong in "backports". Realize that backports is now enabled by default
> in Jessie.

That doesn't really change anything.  The same build environment
issues leading to the -security decision for chromium would lead to
the exact same conclusion in -backports.

Best wishes,
Mike


-- 
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/CANTw=MMaROWK=50of2-gxr40h5+nokuchtzgwuovnsp4p9a...@mail.gmail.com

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Michael Gilbert]

On Mon, Feb 2, 2015 at 11:46 AM, Paul van der Vlis wrote:
> I think it's a good idea to do a backport of the build-system after
> freeze-time of testing. Then we know what the new build-environment is
> for the coming release.
>
> I can understand that Michael does not have the time and motivation for
> such a backport, Chromium will take much time. But maybe others have.

The backports team expects backporters to have demonstrated competence
with the packages that they're planning to upload.  Anyone considering
this should first get involved with the package maintenance teams
first and help with a few unstable uploads.

> And there will be more packages with this problem, e.g. Iceweasel and
> Icedove.

There are unlikely to be any other packages facing the build
environment problem during wheezy's lifetime, so it's quite likely not
worth the effort.

The reason being that very few packages are security maintained with
new upstream versions anyway (iceweasel, mysql as examples), and
chromium is the only one known to be willing to entirely break support
so quickly.

Best wishes,
Mike


-- 
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/CANTw=moohrgckgbnpmgt3cpyv+rhz+4xbietrtzgtifwn2l...@mail.gmail.com

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Michael Gilbert]

On Sun, Feb 1, 2015 at 9:52 PM, Russell Coker wrote:
> On Sun, 1 Feb 2015 11:18:43 PM Paul Wise wrote:
>> chromium was already being backported to wheezy for security updates,
>> the latest versions need newer compilers so we can't backport any
>> more.
>
> Why can't we backport the compilers too?

As mentioned already it was discussed [0], and the release team seemed
willing to consider the idea.  I simply didn't have the time or
motivation myself to do it.

If there were someone willing to maintain it, and work through the
process, it could thus theoretically be done.

Best wishes,
Mike

[0] http://bugs.debian.org/763278


-- 
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/CANTw=MMoaV7za34PCz35cj5nv9NJuo=sW7K=l-dozgb7b0j...@mail.gmail.com

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Michael Gilbert]

On Sun, Feb 1, 2015 at 12:15 AM, Chris Frey wrote:
> Can someone please point me to the upstream announcement for
> dropping gcc 4.7 support?  I can't seem to find it, and I'd like
> to read up on the details why.

The answer is in the previous mail I sent.  The short answer is C++11.

Best wishes,
Mike


-- 
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/CANTw=MMeYqqqWiB2kU6Z7=cnk8-wban3cb21vs5rxfg0wno...@mail.gmail.com

Re: [SECURITY] [DSA 3148-1] chromium-browser end of life

[Michael Gilbert]

On Sat, Jan 31, 2015 at 5:44 PM, Darius Jahandarie wrote:
>> Security support for the chromium web browser is now discontinued
>> for the stable distribution (wheezy).  Chromium upstream stopped
>> supporting wheezy's build environment (gcc 4.7, make, etc.), so
>> there is no longer any practical way to continue building security
>> updates.
>
> How unfortunate.
>
> Was this due to the chromium team not being aware of this consequence?

No, it was a conscious decision (they considered Debian specifically):
http://phajdan-jr.blogspot.com/2014/08/can-your-distro-compile-chromium.html

> What can we do to make it easier and more compelling for upstreams to
> continue supporting popular build environments needed for keeping the
> internet safe?

Another option is to update build environments to support all of the
features upstreams want to use, but that doesn't fit well with
Debian's long-term stable model.  I spent time looking into that, but
with jessie releasing soon (with a sufficient build environment), I
didn't have the motivation or time to do that.

Best wishes,
Mike


-- 
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/CANTw=mmm2pogyvzuxzdycgvh54rqhc-klr-trruw0+oon1w...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 3:13 PM, Andrew McGlashan wrote:
> Google did have OCSP, but they deliberately removed it recently.
>
> FWIW, Steve Gibson has a very good take on all of this.
>
> The OCSP server not found issue is rare, in the past the /main/ CA's got
> together to discuss the OCSP issue and they create CDN's to deal with
> issues like not being able to connect the OCSP server.  The page that
> was linked from /google's/ pov  ... was quite old btw.
>
> Google pushed back on OCSP when Steve Gibson had much to say about the
> whole revocation mess and he talked about alternative ideas that the
> industry is considering.  The CA's backed Steve's take and can't seem to
> understand why Google would push back so hard to go against the OCSP
> idea and other possible solutions.

So, I think you're putting too much faith in the cult of personality.

Google's arguments from 2011 and 2012 are still perfectly valid today:
https://www.imperialviolet.org/2011/03/18/revocation.html

And they are in fact looking into must staple as a solution, but
certificates lifetimes need to be reduced to days or less rather than
years first:
https://www.imperialviolet.org/2014/04/19/revchecking.html

That's an incredibly difficult political, rather than technical
problem.  It's up to the entire ecosystem to move toward short-lived
certificates, and that isn't happening any time soon.  All other
existing solutions are simply "security theater".

In the meantime, Google has decided to avoid those theatrics by
clearly stating not to trust anything, and I personally respect that
honesty.

Best wishes,
Mike


-- 
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/CANTw=mmtupagz-0gduwjpdeehupjyrhmogzomze+gvfth9s...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 1:46 PM, Andrew McGlashan wrote:
> We may see certificate stapling as an answer, but that won't be enough
> if it cannot be certified to /require/ stapling in the cert itself.
> There may be other solutions in time.
>
> You are right in saying that the whole certificate revocations model is
> flawed, but not as flawed as what Google is choosing to use in CRLset.
> Quite simply, Google's response to this problem is a joke.

It sounds like you've got a stinging itch there, so feel empowered to
go scratch it.  I'm sure Google would be interested in a nice patch
set solving this problem once and for all.

Best wishes,
Mike


-- 
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/CANTw=mpsc+psvbn-qacjm4hxfdgoidihl6an-dw7sb5torm...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 12:19 PM, Kurt Roeckx wrote:
> This is a manual, I currently see no need to automate it.

Does buildd.debian.org provide any information about the up to
dateness of its chroots?  If this kind of information were available,
it would help to determine whether a request for updating should be
done prior to doing a security upload.

Best wishes,
Mike


-- 
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/CANTw=mo81skzzd4lxlexwj1lmjqfbrpxozqelm47zm36www...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 11:28 AM, Kurt Roeckx wrote:
>> It could be nice if the stable buildds were kept more up to date.
>> I've CC'd am...@buildd.debian.org to get their opinion on that.
>
> I've just updated the chroots.  But there is reason to be
> concerned that it was build against when there were some
> older packages installed.

Will this be done automatically after future point releases, or is
this always a manual process?

Best wishes,
Mike


-- 
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/CANTw=MPjFHO5C63uedDt5AE9+wzrhV54h3jzCKbKa141Shm1=q...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 7:44 AM, Andrew McGlashan wrote:
> Does Chromium suffer from the Google decision to make use of OCSP
> impossible?  Therefore, an untrustworthy browser.

Basically, the answer is the design of certificate revocation is
fundamentally flawed, and Google have their own security model:
http://www.imperialviolet.org/2012/02/05/crlsets.html

That should not in any way lead to the conclusion that chromium or
google chrome are untrustworthy.  It just means that Google uses an
alternative approach to a fundamentally unsolvable problem.

Best wishes,
Mike


-- 
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/CANTw=MP84m0OdYFSaZb2EZypRU4yfdSWYHXfOKPQAy=vi1c...@mail.gmail.com

Re: [SECURITY] [DSA 2939-1] chromium-browser security update

[Michael Gilbert]

On Sat, May 31, 2014 at 5:27 AM, Georgi Naplatanov wrote:
> When I choose "About Chromium" menu item it says:
>
> Version 35.0.1916.114 Built on Debian 7.1, running on Debian 7.5 (270117)
>
> Is that true that package for AMD64 is built on Debian 7.1?
> If yes, is using of this package secure?

Yes, that is correct.  The reason you're seeing that is that the amd64
package was built on one of the wheezy security build daemon chroots,
which apparently has not been updated in a while.

It's not really a problem since only library headers are used at build
time, and those don't change over the lifetime of the stable release.
As long as the system libraries chromium links against on your machine
are up to date, there is no issue at all.

It could be nice if the stable buildds were kept more up to date.
I've CC'd am...@buildd.debian.org to get their opinion on that.

Best wishes,
Mike


-- 
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/CANTw=MPkaxURA=+WKDSe0Xh8KEL2onz+f-62qP+=zk5wsnf...@mail.gmail.com

Re: Debians security features in comparison to Ubuntu

[Michael Gilbert]

> The problem is, that Debian lacks a page similar to:
> https://wiki.ubuntu.com/Security/Features
>
> As you can see, that https://wiki.ubuntu.com/Security/Features page
> looks impressive to new users. I guess Debian is losing a few users to
> Ubuntu, because Debian does not have such a page.

Most of those features are also in debian, and the lack of a marketing
page shouldn't so easily lead to that conclusion.

Things get done in debian by volunteers, so the short falls that
remain will only be addressed when those with the itch step up to fix
them.

Best wishes,
Mike


-- 
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/CANTw=MNeFuubRRBQTTC0Ytu4q_UcZU+S5ZSXqZbL=xyj80j...@mail.gmail.com

Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.

[Michael Gilbert]

On Thu, Jan 2, 2014 at 6:36 PM, Daniel Curtis wrote:
>
> Hello everyone,
>
> Michael web site with a statistic I've watching for time to
> time. Also Debian Hardening wiki page I studied a couple of
> time.
>
>> There is a lintian check for setuid binaries (...)
>> There isn't really any group effort tackling or monitoring
>> the assortment of useful hardening features (...)
>
> Are you trying to say, that this problem is almost without
> checking, auditing etc.? You're right - there isn't really any
> group effort tackling to adding/enabling additional Security
> Features. Ubuntu and openSUSE doing perfectly job in this
> arena. Both system using many interesting features, which
> aren't available in Debian.

There simply isn't a cohesive team working on that anymore, but as
upstreams do adopt hardening features, it does eventually get pulled
in.  Debian operates on volunteer interest.  If there aren't
volunteers, things unfortunately don't get done.
> Anyway, it could be very nice if Debian would start to
> implement AppArmor for serious - put all effort on this
> (yes, there is also SELinux) because it's very simple,
> intuitive, contains many profiles etc. SELinux is also good,
> but is complex. Of course there is openSUSE and Ubuntu
> with AppArmor so everything is even easier.

It's only going to get done if there are volunteers interested in
working on that.  You're already interested, so you're in the best
position to make it happen?

Best wishes,
Mike


-- 
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/CANTw=movzd4u9nd_tzrtjaj3nws6coxr4u6qibc237rmdek...@mail.gmail.com

Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.

[Michael Gilbert]

On Wed, Jan 1, 2014 at 12:24 PM, Daniel Curtis wrote:
> Hi Moritz,
>
> 90 percent of the hardening via 'dpkg-buildflags'? That's
> a good information. I'd hoped, that the majority of all base
> packages and that's security-sensitive will be protected
> well. It's really a huge satisfaction.

You can also follow total archive buildflag progress:
http://outflux.net/debian/hardening

And consider helping:
https://wiki.debian.org/Hardening

> One more thing - does Debian include something like e.g.
> Ubuntu or openSUSE does? I mean a Security Features field.
> To mention a few: setuid binaries (kept to minimum),
> minimal set of daemons in the default instalation, no open
> ports or ptrace scope (via /kernel/yama/ptrace_scope sysctl),
> and so on. What about kernel hardening?

There is a lintian check for setuid binaries, which prompts
maintainers to avoid that.

There isn't really any group effort tackling or monitoring the
assortment of useful hardening features.  That is something that could
definitely be improved.  There are ubuntu pages on their progress in
that area that may be worthwhile checking to see where debian stands.

Best wishes,
Mike


-- 
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/CANTw=mn2brwy9g0yeid-u-9tdmrjz9tv-tyll3_ij_hyqz4...@mail.gmail.com

Re: MIT discovered issue with gcc

[Michael Gilbert]

On Sat, Nov 23, 2013 at 4:52 PM, Jann Horn wrote:
> On Sat, Nov 23, 2013 at 08:14:34AM -0500, Brad Alexander wrote:
>> Any program at a level not very much above Hello World
>> in the language of your choice is likely to have bugs.
>
> Isn't that a bit extreme? I think that a good programmer who seriously
> tries to code carefully should be able to implement something like an FTP
> server with 90% certainty that there are no bugs. Not a complicated one
> with a ton of features, but a simple one should IMO be doable.

The history of software development has, so far, shown the opposite.
Any non-trivial program, regardless of the skill of the coder, will
have flaws; including a simple ftp server.   There are multiple tftp
(trivial ftp) implementations, all of which have had CVE ids issued at
some point.

Best wishes,
Mike


-- 
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/CANTw=MMZ0sjdFajK9qw9TLhtW6NywTUPBj+fiOhz=ej23z3...@mail.gmail.com

Re: [SECURITY] [DSA 2797-1] chromium-browser security update

[Michael Gilbert]

On Sun, Nov 17, 2013 at 10:42 AM, Michael Gilbert wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> - -
> Debian Security Advisory DSA-2797-1   secur...@debian.org
> http://www.debian.org/security/           Michael Gilbert
> November 16, 2013  http://www.debian.org/security/faq
> - -
>
> Package: chromium-browser
> Vulnerability  : several
> Problem type   : remote
> Debian-specific: no
> CVE ID : CVE-2013-2931 CVE-2013-6621 CVE-2013-6622 CVE-2013-6623
>  CVE-2013-6624 CVE-2013-6625 CVE-2013-6626 CVE-2013-6627
>  CVE-2013-6628 CVE-2013-6629 CVE-2013-6630 CVE-2013-6631
>  CVE-2013-6632
>
> Several vulnerabilities have been discovered in the chromium web browser.

Just to clarify, a preexisting icedove DSA number was mistakenly re-used
for this announcement.  The correct number for this (chromium)
security announcement is DSA-2799-1.

Best wishes,
Mike


-- 
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/CANTw=mn3+gbw42ahw4kgmd8ykretwks6mo6ydiztzikem3o...@mail.gmail.com

Re: How (un)safe would Debian be when only using the security.debian.org repository?

[Michael Gilbert]

On Mon, Nov 11, 2013 at 11:20 PM, Paul Wise wrote:
> On Tue, Nov 12, 2013 at 6:30 AM, Michael Gilbert wrote:
>
>> Which confirms my point.  That asterisk update, for example, required
>> no new package dependencies outside the security archive.
>
> You said no deps outside the security archive, not no new deps outside
> the security archive.

I agree, those 4 characters would have eliminated any opportunity for
that statement to be misread.

Best wishes,
Mike


-- 
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/CANTw=MMg_4Ue=be1jzw1anpkmfy9d_nh4dzfopha6pqpdqz...@mail.gmail.com

Re: How (un)safe would Debian be when only using the security.debian.org repository?

[Michael Gilbert]

On Mon, Nov 11, 2013 at 5:06 PM, Bastian Blank  wrote:
> On Mon, Nov 11, 2013 at 04:56:27PM -0500, Michael Gilbert wrote:
>> That isn't quite right since excepting mistakes, security updates will
>> never require packages outside the security archive.
>
> This is incorrect:
>
> | Package: asterisk-mysql
> | Depends: […] libc6 (>= 2.4), […]
>
> | $ apt-cache policy asterisk-mysql | grep wheezy
> | 500 http://security.debian.org/ wheezy/updates/main amd64 Packages
> | 500 http://ftp.de.debian.org/debian/ wheezy/main amd64 Packages
>
> libc6 is _not_ shipped in the security archive:
>
> | $ apt-cache policy libc6 | grep wheezy
> | 500 http://ftp.de.debian.org/debian/ wheezy/main amd64 Packages

Which confirms my point.  That asterisk update, for example, required
no new package dependencies outside the security archive.

Best wishes,
Mike


--
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/CANTw=MO_n2vX2ot8xoQAGrisyr�yv3xcwcwr_scdrg_ou...@mail.gmail.com

Re: How (un)safe would Debian be when only using the security.debian.org repository?

[Michael Gilbert]

On Mon, Nov 11, 2013 at 6:17 AM, Norbert Kiszka wrote:
> Missing dependencies can break upgrade. For ex. one package from
> security-update can depend on other package, so it will not be
> installed. Unless You install it by hand.

That isn't quite right since excepting mistakes, security updates will
never require packages outside the security archive.

Best wishes,
Mike


-- 
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/CANTw=MMe11KAMAZmqaqZnW=bs-1smrtq+2ccknx-arhe9pk...@mail.gmail.com

Re: How (un)safe would Debian be when only using the security.debian.org repository?

[Michael Gilbert]

On Sun, Nov 10, 2013 at 2:50 PM, adrelanos wrote:
> Hi!
>
> How (un)safe would it be...? When using Debian while...
>
> Not using:
> deb http://ftp.us.debian.org/debian stable main contrib non-free
> deb http://security.debian.org stable/updates main contrib non-free
>
> Only using:
> deb http://security.debian.org stable/updates main contrib non-free

You would no longer get any point release updates, which while only
occurring every few months, often involve a lot of minor security
updates.

> Not using:
> deb http://ftp.us.debian.org/debian testing main contrib non-free
> deb http://security.debian.org testing/updates main contrib non-free
>
> Only using:
> deb http://security.debian.org testing/updates main contrib non-free

You would no longer get any updates at all, security or otherwise,
since testing security updates no longer done via uploads to
testing-security.  They are done via uploads to unstable that
eventually transition.

Best wishes,
Mike


-- 
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/CANTw=mnzk1x_5gv5zv2o+xgqrbokbj4f5q5bm6fkmy-nyo5...@mail.gmail.com

Re: [SECURITY] [DSA 2698-1] tiff security update

[Michael Gilbert]

On Wed, Jun 19, 2013 at 4:35 PM, Kurt Roeckx wrote:
> On Wed, Jun 19, 2013 at 06:55:57PM +, Roland Karch wrote:
>> Indeed I am. And I got it from wheezy:
>>
>> http://packages.debian.org/wheezy/libtiff4
>>
>>
>> And me running the version just between those was, well... part of why I 
>> asked my original question.
>
> So it seems we have those source packages:
>  tiff | 3.9.4-5+squeeze8 | squeeze  | source
>  tiff | 3.9.4-5+squeeze9 | squeeze-security | source
>  tiff | 4.0.2-6  | wheezy   | source
>  tiff | 4.0.2-6+deb7u1   | wheezy-security  | source
>  tiff | 4.0.2-6+nmu1 | jessie   | source
>  tiff | 4.0.2-6+nmu1 | sid  | source
>  tiff3| 3.9.6-11 | wheezy   | source
>  tiff3| 3.9.6-11 | jessie   | source
>  tiff3| 3.9.6-11 | sid  | source
>
> And the update was only for the "tiff" source package, not for the
> tiff3 that's also in wheezy.
>
> The security tracker seems to be missing the information on the
> tiff3 source package.

I was not aware that there was a tiff3 source package until just now,
but we're starting to triage the situation:
https://bugs.debian.org/712840

Best wishes,
Mike


-- 
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/CANTw=MM5y_=rj3taqpx8t_iwlfsh8uwkgpi32ecjpvj9j8v...@mail.gmail.com

Re: [SECURITY] [DSA 2695-1] chromium-browser security update

[Michael Gilbert]

On Sun, Jun 2, 2013 at 11:51 AM, Nick Boyce wrote:
> On Sunday 02 Jun 2013 16:13:43 Michael Gilbert wrote:
>
>> On Sun, Jun 2, 2013 at 9:32 AM, Nick Boyce wrote:
>>
>> > On Wednesday 29 May 2013 15:23:54 Michael Gilbert wrote:
>> >
>> >> or possibly have unspecified other impact via unknown vectors.
>> >
>> > I'm just wondering ... is that Google language for "or possibly allow
>> > remote code execution" ?
> [...]
>> That is the intentionally vague language of CVE (e.g.
>> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2837).
> [...]
>> In terms of chromium, your best bet is simply to wait for the bugs to
>> become unembargoed (e.g.
>> https://code.google.com/p/chromium/issues/detail?id=235638).
>
> Thanks.  It's just that I tend to expect that by the time a security fix is
> released, those bugs *are* unembargoed, researchers are poring over code 
> diffs,
> and clear descriptions are usually forthcoming cos there's no longer any point
> in being coy.  For instance, by the time a Firefox release is made Mozilla
> states explicitly in the release information whether or not each bug could
> cause rce.  Same thing for Microsoft.

It's really Google's decision to make, and they have a statement in the faq:
http://www.chromium.org/Home/chromium-security/security-faq

Unfortunately their bugs tend to be embargoed for months (and I've
seen a couple take over a year), which doesn't really live up to the
spirit of their new 7 day policy, but then again that is only for
issues that are known to be exploitable in the wild:
http://googleonlinesecurity.blogspot.com/2013/05/disclosure-timeline-for-vulnerabilities.html

You can always try pestering them at secur...@chromium.org.  It's
probably more of a matter of neglect than intentional.

Best wishes,
Mike


-- 
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/CANTw=MN9fOchcfLeGRzkCrgFib-O1jJi+7SAafp=bugz0qi...@mail.gmail.com

Re: [SECURITY] [DSA 2695-1] chromium-browser security update

[Michael Gilbert]

On Sun, Jun 2, 2013 at 9:32 AM, Nick Boyce wrote:
> On Wednesday 29 May 2013 15:23:54 Michael Gilbert wrote:
>
>> or possibly have unspecified other impact via unknown vectors.
>
> I'm just wondering ... is that Google language for "or possibly allow remote
> code execution" ?
>
> The phrase occurs for many of the vulnerabilities listed in the advisory, and
> most browser release notices cure some bugs that may allow remote code
> execution ... but not one of the vulnerabilities listed in this one refers to
> rce.
>
> I'm wondering whether the phrasing of the descriptions of the CVEs listed in
> this advisory is Google's choice .

That is the intentionally vague language of CVE (e.g.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2837).

The do that because there are an incredibly large number of issues per
year (getting close to 10,000/year now), and it is unfeasible to have
someone accurately study and write-up every one of them.

In terms of chromium, your best bet is simply to wait for the bugs to
become unembargoed (e.g.
https://code.google.com/p/chromium/issues/detail?id=235638).

Best wishes,
Mike


-- 
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/CANTw=MNhkwyQW0=ssvdnotrecwr2y+qbn-591ofqnuensv7...@mail.gmail.com

Re: flashplugin-nonfree get-upstream-version.pl security concern

[Michael Gilbert]

On Wed, Dec 12, 2012 at 11:41 PM, Jason Fergus wrote:
> On Wed, 2012-12-12 at 17:26 -0500, Michael Gilbert wrote:
>> On Wed, Dec 12, 2012 at 12:52 PM, adrelanos wrote:
>> > What is Debian policy on code execution from user websites?
>>
>> Unfortunately there is none.  I've tried to gain consensus that at a
>> minimum things downloaders like this need to stay out of main, but
>> that thought hasn't really gained traction.
>>
>> The real answer is that this package is in contrib and thus not
>> security supported at all.  Ultimately, for anyone even modestly
>> security-conscious adobe flash should really be avoided at all costs.
>> Alternatives include lightspark, gnash, and (most preferably) html5.
>>
>> Best wishes,
>> Mike
>>
>>
> I could be wrong on this, but I had always thought that ANY sort of
> downloader type installer (like the flashplugin-nonfree package) could
> NOT be in main.  For any package to be in main, it has to have source
> code available as well as DFSG compliant.  It's the same reason why
> quake2-data packages were always in contrib.  While the source code for
> quake2 is GPL, the -data package would grab the pk0.pak files off of the
> CD to put them in the proper place for global Quake 2 fun.  quake2-data
> was always in contrib.  I was going to use qmail as an example, but I am
> guessing they changed their license recently, because previous to
> Wheezy, you always had to build it from source (and there was a
> qmail-src package).

You would think that, but Debian policy has nothing to say.  I put a
lot of energy into it, but things like getweb still remain:
http://bugs.debian.org/449497

These cases are actually pretty rare, which is the real reason that
there is no defined policy.  Plus people tend to not like repacking
upstream due to single questionable files.

> Anyhow, I hope that point was made clear.  Contrib also does get
> security updates, but they're not maintained by the security team (if
> I'm recalling correctly.  Sucks getting old).  They're simply maintained
> by the package maintainer.

Well, there's always the option for the maintainer to provide a
security update an spu, but that is so rare in contrib that I don't
recall the last time it happened.

Without security team intervention happens in probably 95% of cases
for security issues, so there's something like a 5% of a fix going
into contrib.  Maintainers tend to lose interest in the stable release
fairly quickly.

Best wishes,
Mike


-- 
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/CANTw=mnek8zlybcnz+ebxv-qg6ez4h92bjd8xi_xe6fuxbh...@mail.gmail.com

Re: flashplugin-nonfree get-upstream-version.pl security concern

[Michael Gilbert]

On Wed, Dec 12, 2012 at 12:52 PM, adrelanos wrote:
> What is Debian policy on code execution from user websites?

Unfortunately there is none.  I've tried to gain consensus that at a
minimum things downloaders like this need to stay out of main, but
that thought hasn't really gained traction.

The real answer is that this package is in contrib and thus not
security supported at all.  Ultimately, for anyone even modestly
security-conscious adobe flash should really be avoided at all costs.
Alternatives include lightspark, gnash, and (most preferably) html5.

Best wishes,
Mike


-- 
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/CANTw=MOB8g0L-TwBeFmgTAd68wv=djwjkffszhhptrgc9he...@mail.gmail.com

Re: CVE-2011-1521 and CVE-2011-3389 - fixed packet

[Michael Gilbert]

On Mon, Oct 1, 2012 at 12:34 PM, Arne Wichmann wrote:
> Hi,
>
> First: Could somebody perhaps enlighten me why all these issues show up
> as unimportant in [2] but up to medium in the separate pages (e.g. [3])

That seems to be a tracker bug (possibly involving [squeeze],etc
release-specific tags).  If all releases have fixed versions, it
should be considered a fixed issue, but it wasn't.  However, for that
specific case, I've just checked and the issue is not fixed in
2.6.6-8, so I reverted that change.

I'll take a look at the rest in the next couple days.

Best wishes,
Mike


-- 
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/CANTw=MOyDPjdkqrGLzeTPNfuwWLy=pMX6hL4W0dc=rbud8h...@mail.gmail.com

Re: CVE-2011-1521 and CVE-2011-3389 - fixed packet

[Michael Gilbert]

On Mon, Sep 24, 2012 at 4:27 AM, Arne Wichmann  wrote:
> begin  quotation  from Michael Gilbert (in ):
>> On Fri, Sep 21, 2012 at 11:40 AM, Arne Wichmann wrote:
>> > Ok, I just created one more fixed version of python2.6 for my own use.
>> > Whoever is interested can find it at [1] for the time being. If anybody has
>> > comments or improvements I am also interested.
>>
>> Would you mind attaching a debdiff so we can see what you did?  If
>> your changes look reasonable, I may be willing to work with you to
>> sponsor a stable-proposed update:
>> http://www.debian.org/releases/proposed-updates
>
> Attached.

Thanks for your work on this.  There are a couple easily correctable
issues.  One is that the debdiff is backwards.  Second, its better to
use cve numbers to name the patches rather than commit ids.  Third,
the distribution should be stable-proposed-updates rather than stable,
and there should only be one new entry in the changelog, and the
version should be +squeeze1.

Finally, there are some other unfixed python2.6 issues.  Would you
mind taking a look at those?  It would be good to include them all in
a new update:
http://security-tracker.debian.org/tracker/source-package/python2.6

Thanks again!
Mike


-- 
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/CANTw=MMmOqRrK-g9gmLndxmxXxkYO3zwaDCis_hSvo2=n77...@mail.gmail.com

Re: CVE-2011-1521 and CVE-2011-3389 - fixed packet

[Michael Gilbert]

On Fri, Sep 21, 2012 at 11:40 AM, Arne Wichmann wrote:
> Ok, I just created one more fixed version of python2.6 for my own use.
> Whoever is interested can find it at [1] for the time being. If anybody has
> comments or improvements I am also interested.

Would you mind attaching a debdiff so we can see what you did?  If
your changes look reasonable, I may be willing to work with you to
sponsor a stable-proposed update:
http://www.debian.org/releases/proposed-updates

Best wishes,
Mike


-- 
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/CANTw=MPSr5+TBwG=xaxpgk0vbiw93va4_7enoev_wzbmxwg...@mail.gmail.com

Re: Removal of email address from security announcement list

[Michael Gilbert]

On Thu, Sep 13, 2012 at 1:40 PM,   wrote:
> Pease remove the following address from any debian mail lists:

You have the ability to do that yourself:
http://www.debian.org/MailingLists/unsubscribe

Best wishes,
Mike


-- 
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/CANTw=MMfiEURYK5QbmJ=vtvhjquczrzkmwyxfc57q17g9hy...@mail.gmail.com

Re: CVE-2012-1033 (bind9)

[Michael Gilbert]

On Thu, Jul 26, 2012 at 10:50 AM, Mike Ashton wrote:
> Hello folks,
>
> If we look here:
>
> http://security-tracker.debian.org/tracker/CVE-2012-1033
>
> it appears as though this CVE has been written off as a DNS protocol
> flaw, I believe based on the original ISC announcement here:

Hi, this had already been fixed in unstable/testing before your
message.  It's a low severity issue, and if you want to see it fixed
in squeeze, you could help by preparing an stable-proposed-update for
the next point release.

In the meantime, I've updated the tracker.

Thanks,
Mike


-- 
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/CANTw=MPd0pXdRY+CoiG9d=AO6J_f12t-vQYYEjfe+PC7=tf...@mail.gmail.com

Re: Please ensure an RC bug is open when DSA fixes are missing in testing/unstable

[Michael Gilbert]

On Thu, Jul 26, 2012 at 5:54 PM, Adrian Bunk wrote:
> Many DSA's contain "For the unstable (sid) and testing (wheezy)
> distribution, this problem will be fixed soon."
>
> When there is an unfixed version in testing and/or unstable, please
> ensure an RC bug is open. Otherwise there is the possibility that
> a new Debian release might ship with vulnerabilities that were fixed
> through a DSA in a previous Debian release.

If this issue bothers you, then you are in the best position to fix it
-- by volunteering.

Also, we do have the security-tracker, which does have up-to-date info:
http://security-tracker.debian.org/tracker/source-package/isc-dhcp

Best wishes,
Mike


-- 
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/CANTw=mmrfmlf85ard-jqsi5mu0au_-7xbdpx5_kspevech0...@mail.gmail.com

Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies

[Michael Gilbert]

On Mon, Jul 2, 2012 at 1:59 PM, Petter Reinholdtsen wrote:
>
> [Silvio Cesare]
>> I recently ran the tool and cross referenced identified code copies with
>> Debian's security tracking of affected packages by CVE. I did this for all
>> CVEs in 2010, 2011, and 2012.
>
> This sound like a job that could become a bit easier if we tagged
> Debian packages with the CPE ids assosiated with CVEs, to make it
> easier to figure out which Debian package are affected by a given CVE.
>
> Are you aware of my proposal to do this, mentioned on debian-security
> and also drafted on http://wiki.debian.org/CPEtagPackagesDep >?

Does this actually cover embedded code copies?  The spec probably
needs to get something like an "XBS-Embeds-Source-From-CPE" tag for
that.

Even so, do you think maintainers are really going to go through the
trouble to keep these tags accurately populated?  I suppose its worth
it to try, but I have my doubts.  Inaccurate information can be worse
than no information.  At least with embedded-code-copies, we have a
centralized record that's kept up to date by security-involved people.

Best wishes,
Mike


-- 
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/CANTw=MNq6=9rBjjcM-CvkB13v8S=v1va12ydt_r-es1qu5x...@mail.gmail.com

Re: Xorg: Security past client auth.

[Michael Gilbert]

On Sun, Jun 10, 2012 at 12:03 PM, Mike Mestnik
 wrote:
> To be honest I can't say one way or another about weather there are
> security issues in X if one has malicious clients connected.
>
> However I'm not having success discussing these matters over at
> xorg-de...@lists.x.org.  I'm not the most likable person and I've even
> recently discovered that there a ppl who won't hesitate to pick on me.
> I can understand why ppl don't like me and that I have issues correctly
> expressing myself, even so I belive that what I'm trying to say is
> important.  I believe that a discussion and perhaps further
> documentation on the security of X and more importantly the future
> security of X is overdue.
>
> For the purposes of this discussion I'd like to use a vary loose
> definition for malicious clients, to include any client running on a
> remote(from the X server) system.  I believe that any system can be
> compromised and thus unknowingly be running a rootkit.  There should be
> layers of security that would limit the effectiveness of such an attack.
>  I belive doing so will cause Malicious Programmers and Users to be less
> likely to develop and deploy rootkits that have hooks into xclients to
> attack remote X servers.
>
> Therefore it's my assumption that a lack of security in this area would
> make the once Network Transparent Windows System, less useful over any
> network and promote the spread of any type of rootkit.
>
> This started after I read A LWN article about the [1]story of the XInput
> multitouch extension.  It seams that this extension may leak sensitive
> information to malicious clients.
>
> 1. http://lwn.net/Articles/485484/
>
> I wanted to discuss the issue with the grater X community, believing
> that what code to accept and reject as patches was indeed on-topic for
> xorg-de...@lists.x.org I [2]posted over there first.
>
> 2. http://lists.x.org/archives/xorg-devel/2012-June/031561.html
>
> I was eventually moderated and have lost my ability to speak in that
> forum.  This alone tells me that I need to keep trying, there is
> obviously some form of oppression going on here as me myself have been
> oppressed.

By default, the Debian X packages launch with "-nolisten tcp" to avoid
the inherent issues in xorg's tcp implementation.  You can however
still access remote X via ssh or other more secure means.

Actions speak loader than words, so if you can demonstrate the
weakness some existing unfixed issue, then by all means, that is a
much better way to communicate your message.

Best wishes,
Mike


--
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/CANTw=mm5brxg-wmf32he2usbz49d7x31mo_m-6+sg3hevob...@mail.gmail.com

Re: CVE-2011-1521 - python update for squeeze?

[Michael Gilbert]

On Mon, Apr 23, 2012 at 4:12 AM, Andrea Zwirner wrote:
> I would be glad to make this one my first contribute to debian, can you just
> route me to the right manuals to do it?

Here is a link to info about proposed-updates:
http://www.debian.org/releases/proposed-updates

Here is a link to the info in the security tracker:
http://security-tracker.debian.org/tracker/CVE-2011-1521

Doing some research there will lead to this upstream bug report, which
will likely be the best place to start to determine an appropriate
fix:
http://bugs.python.org/issue11662

Best wishes,
Mike


-- 
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/CANTw=MMvc-Vb9QFG+djf6_hr4oz2gCzgLe=69mt-ftvku9e...@mail.gmail.com

Re: CVE-2011-1521 - python update for squeeze?

[Michael Gilbert]

On Sun, Apr 22, 2012 at 1:13 PM, Arne Wichmann wrote:
> Hi...
>
> Is there an intention or interest to create a python update which fixes
> CVE-2011-1521 for squeeze?

>From what I'm aware, there is currently no plan for that; although
anyone interested in the problem can take the initiative to prepare a
stable-proposed-update.

Best wishes,
Mike


-- 
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/CANTw=moi0epfvl3wevtsq3j7bfnbwcjmnzsdn76aqej6rwe...@mail.gmail.com

Re: Samba Root CVE-2012-1182 - Possibly countered with hardening@compiletime ?

[Michael Gilbert]

On Tue, Apr 17, 2012 at 6:15 AM, Crusty Saint wrote:
> Hi,
>
> Regarding https://www.samba.org/samba/security/CVE-2012-1182
>
> I'm currently step-by-step looking into compiling my own debs and
> recompiling existing once ( ignoring that optimisations are often
> overrated ) What i'm most interested in though is the
> hardening@compile-time of packages. Even if this means generic
> protection. Thinking some is better then none. For this i've, so far,
> used hardening-wrapper and hardening-includes packages. Though i'm not
> sure if i'm even using hardening-includes correctly at this time i
> dare to present a question.
>
> Part of the description of the CVE reads :
>
> "The flaw caused checks on the variable containing the length of an
> allocated array to be done independently from the checks on the
> variable used to allocate the memory for that array.  As both these
> variables are controlled by the connecting client it makes it possible
> for a specially crafted RPC call to cause the server to execute
> arbitrary code."
>
>
> Would recompiling with a DEB_BUILD_HARDENING=1 and corresponding
> configuration as below in /etc/hardening-wrapper.conf have mitigated
> against this particular exploit vector ? Though part of the attack
> depends on logic i assume the 'specially crafted RPC call' could've
> been mitigated against.

I don't really have an answer since I have not personally studied this
issue, but anyone that may have interest in any particularr security
issue can made use of the informative debian security tracker as a
spring board for their own research.

For example, if I wanted to better understand this issue, I would
start at [0], which would eventually lead me to [1], which includes
patches that samba applied.  I could then study those to see if
hardening made a difference.

> *glops* My /etc/hardening-wrapper.conf looks like
>
> DEB_BUILD_HARDENING=1
> DEB_BUILD_HARDENING_DEBUG=0
> DEB_BUILD_HARDENING_STACKPROTECTOR=1
> DEB_BUILD_HARDENING_RELRO=1
> DEB_BUILD_HARDENING_FORTIFY=1
> DEB_BUILD_HARDENING_PIE=1
> DEB_BUILD_HARDENING_FORMAT=1

It's quite a bit easier now.  You can set debian/compat to 9 in the
source package, and hardening will be done automagically (you may also
want to set "export DEB_BUILT_MAINT_OPTIONS=hardening=+all" in
debian/rules to get all hardening enabled).

Best wishes,
Mike

[0] http://security-tracker.debian.org/tracker/CVE-2012-1182
[1] https://bugzilla.samba.org/show_bug.cgi?id=8815


--
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/CANTw=mpc0fnfb3kbfhw2xhxvmatjzdhuhfcfa2p6+dotxi6...@mail.gmail.com

Re: Security response: how are we doing?

[Michael Gilbert]

On Thu, Dec 1, 2011 at 6:11 AM,  wrote:
> On the other hand, at least from my point of view, things are not looking so
> bright. I have on my watchlist 4 buffer overflows (CVE-2011-3193,
> CVE-2011-3194, CVE-2011-1071, CVE-2011-1097), one DoS (CVE-2011-1659) and a
> number of lesser problems (#628843, #615118, CVE-2011-1521), most of which
> I have at least pinged once, most are around for at least 3 months, some
> for more than 6 months. And my selection is a quite limited one.

At least CVE-2011-3194/5 out of your list above are for a package
(qt4-x11) that has been declared as not receiving security support.

Unfortunately volunteers tend to have limited time, and more help is
always appreciated.  Even non-DDs can prepare new package updates for
future DSAs.  Pinging isn't necessarily productive, actual work is.

Help with the tracker is also very useful:
http://anonscm.debian.org/viewvc/secure-testing/doc/narrative_introduction?view=co

Best wishes,
Mike


-- 
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/CANTw=MNYAG06d8jd3=k9i5dflrwv7jrxvudrpftvtitnjxp...@mail.gmail.com

Re: [SECURITY] [DSA 2351-1] wireshark security update

[Michael Gilbert]

On Tue, Nov 22, 2011 at 12:36 AM,  wrote:
> I tried to contact with them to remove autoreply. Unfortunately they didn't 
> reply me at all.
> Seems there is nobody who reads this e-mail.

Usually I would argue that its wrong to forcibly unsubscribe an
address, but in this case since these have come with the past 10 or so
announcements and no one answers the mail, I think it's warranted to
take them off.  Although, it would be nice to send them a message
saying that is being done.

Best wishes,
Mike


-- 
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/CANTw=mn-fps+3yv14lbxhotcps3kgulywjewce0smul9mjx...@mail.gmail.com

Re: CVE-2011-1930: klibc 1.5.12-3 not available for lenny

[Michael Gilbert]

On Sat, Nov 5, 2011 at 7:31 AM, Jörg Sommer wrote:
> Hi,
>
> the security tracker says there was a version 1.5.12-3 released to fix
> the issue CVE-2011-1930 for lenny, but I can't find this version in the
> archive and on snapshot. Has the security tracker wrong informations?

The version number entered into the tracker was wrong.  It's actually
fix.ed in 1.5.12-2lenny1.  I've fixed the tracker data now.

Best wishes,
Mike


--
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/CANTw=mnhl5ysloumzksbwyayjkpymydfqxrtcqdav39b9zn...@mail.gmail.com

Re: Debian LTS?

[Michael Gilbert]

On Thu, 6 Oct 2011 17:50:18 -0700 jor...@envygeeks.com wrote:

> > On Thu, 6 Oct 2011 09:50:12 +0100 Dominic Hargreaves wrote:
> > If money were available, I'm sure there are plenty of skilled project
> > participants that are more than willing to accept it.  It could even be
> > incentive- rather than person-based; something like $500 per LTS DSA to
> > whoever gets it done first.
> 
> Offering $500 to an admin who is already overworked and understaffed isn't
> enough incentive.  TBH, as an Admin myself, I would rather be offered some
> new computer and some time off then any money at all, we aren't broke,
> just over worked.

I don't think the security team considers themselves admins, but anyway, the
amount of money that could be offered by a foundation will likely be modest,
and $500 seemed like a reasonable guess, but who knows until its actually
tried.  Note that $500 is already quite a bit better than the current $0 that
volunteers get for issuing DSAs at present.

Best wishes,
Mike


-- 
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/20111006210411.e11158b3.michael.s.gilb...@gmail.com

Re: Debian LTS?

[Michael Gilbert]

On Thu, 6 Oct 2011 09:50:12 +0100 Dominic Hargreaves wrote:

> On Wed, Oct 05, 2011 at 06:41:32PM -0700, Noah Meyerhans wrote:
> > I agree.  Long-term support is not sexy, and it's not something that
> > most FLOSS developers (or developers in general, in my experience) have
> > any interest in working on.  The best way that most companies know to
> > motivate them is to pay them.  This is why RHEL, Canonical, and other
> > companies charge so much for support contracts.  I'm not sure how
> > anybody could motivate a large enough group Debian developers to work on
> > an LTS release.
> 
> The idea I was raising (based on the security team notes) was along the
> lines of getting a foundation together to fund that work specifically.
> I have no real idea whether there are people around who would be ready
> and willing to do the work on a paid basis, of course, but I can't help
> thinking that the money is likely to be there if the coordination and
> willing expertise is also there (that's a big if, of course).

If money were available, I'm sure there are plenty of skilled project
participants that are more than willing to accept it.  It could even be
incentive- rather than person-based; something like $500 per LTS DSA to
whoever gets it done first.

Best wishes,
Mike


-- 
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/20111006195749.bd79378b.michael.s.gilb...@gmail.com

Re: ksplice for debian kernel DSA's

[Michael Gilbert]

Sergey B Kirpichev wrote:

> Hi,
> 
> Does anyone have used ksplice to patch standard debian
> kernels?  How do you prepare an update for regular kernel DSA's?
> 
> Some time ago Oracle have bought Ksplice and now their
> Ksplice Uptrack for Debian is available for legacy customers
> only.  Probably, it's not a bad idea to provide ksplice patches
> (at least for some DSA) and distribute them across Debian
> own infrastructure, not rely on external services.
> 
> Does this possibility was ever considered by the security
> team (or Debian kernel maintainers)?

Of course anything is possible given a sufficiently interested
volunteer and (of course) time.  If you're interested in as-yet
unavailable features in Debian, you're the best resource to make them
happen.

Best wishes,
Mike


-- 
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/20110928195803.350ca5b9a3d8a040c8bcb...@gmail.com

Re: libpng CVE-2006-7244/CVE-2009-5063

[Michael Gilbert]

Henri Salo wrote:

> There is two open vulnerabilities in libpng 1.2.27-2+lenny4 as you can see 
> from:
> 
> http://security-tracker.debian.org/tracker/source-package/libpng
> 
> The issues I am concerned about are CVE-2006-7244 and CVE-2009-5063. Notes of 
> the issues are: "package libpng is vulnerable; however, the security impact 
> is unimportant.", but I think these aren't unimportant as you can see from 
> here:
> 
> http://www.openwall.com/lists/oss-security/2011/03/22/7
> http://www.openwall.com/lists/oss-security/2011/03/28/6
> 
> Is there a plan to fix these issues? Should I create a bug-report?

The CVE entries describe these issues as denial-of-services, which can
be chosen to be considered unimportant.  Do you have information that
the problem is actually more severe than that?

If you really want to fix this, you can prepare an ospu and send it to
debian-release@l.d.o for review for lenny's next stable update.

Best wishes,
Mike


-- 
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/20110724140306.2b4341292820cea9055fd...@gmail.com

Re: CVE-2011-1071 / #615120 - security fix in stable?

[Michael Gilbert]

Arne Wichmann wrote:

> Hi,
> 
> I see that CVE-2011-1071 (#615120) is done in testing - shouldn't it be
> fixed in stable, too?

Yes, Debian security is done by volunteers with limited time, so the
best way to get things fixed is to volunteer to do the work yourself
(especially in cases like this where no one is working on it).

Best wishes,
Mike


-- 
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/20110618141731.33615f0f.michael.s.gilb...@gmail.com

Re: aptitude upgrade vs. apt-get upgrade

[Michael Gilbert]

On Thu, 31 Mar 2011 13:44:59 -0400 Michael Gilbert wrote:

> On Thu, 31 Mar 2011 15:28:21 +0100 Hector Oron wrote:
> 
> > Hi,
> > 
> > 2011/3/31 Riku Valli :
> > 
> > > apt-get is now preferred method over aptitude at Squeeze. However at
> > > Lenny aptitude is preferred over apt-get.
> > >
> > > You should use apt-get with Squeeze and aptitude with Lenny.
> > 
> > It is recommended on the release-notes for the upgrade from lenny to 
> > squeeze.
> > Aptitude should just work fine on squeeze.
> > 
> > >>> # aptitude -s upgrade
> > >>> The following packages will be upgraded:
> > >>>   bind9-host dnsutils libbind9-60 libdns69 libisc62 libisccc60
> > >>> libisccfg62 liblwres60
> > >>> 8 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> > >>>
> > >>> # apt-get -s upgrade
> > >>> Reading package lists... Done
> > >>> Building dependency tree
> > >>> Reading state information... Done
> > >>> The following packages will be upgraded:
> > >>>   bind9-host dnsutils libbind9-60 libdns69 libisc62 libisccc60
> > >>> libisccfg62 liblwres60
> > >>> tex-common
> > >>> 9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > >>>
> > >>> What's the reason for this?
> > 
> > Can you check which it is the status of tex-common, is it held by any
> > reason? aptitude frontend it is very good to find out such things.
> > 
> > In anycase, I believe this conversation belongs to debian-user@l.d.o
> > and not debian-security@l.d.o
> 
> If there it turns out there is actually a problem in aptitude, then
> keeping debian-security in the loop is a good thing, so don't worry
> about changing mailing list context.  This is a fine place for
> discussion.

I probably should have mentioned that a bug report would probably be
more useful since you'll actually get the aptitude maintainers looking
at the problem (if there is one).

Best wishes,
Mike


--
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/20110331135801.7c0ea97a.michael.s.gilb...@gmail.com

Re: aptitude upgrade vs. apt-get upgrade

[Michael Gilbert]

On Thu, 31 Mar 2011 15:28:21 +0100 Hector Oron wrote:

> Hi,
> 
> 2011/3/31 Riku Valli :
> 
> > apt-get is now preferred method over aptitude at Squeeze. However at
> > Lenny aptitude is preferred over apt-get.
> >
> > You should use apt-get with Squeeze and aptitude with Lenny.
> 
> It is recommended on the release-notes for the upgrade from lenny to squeeze.
> Aptitude should just work fine on squeeze.
> 
> >>> # aptitude -s upgrade
> >>> The following packages will be upgraded:
> >>>   bind9-host dnsutils libbind9-60 libdns69 libisc62 libisccc60
> >>> libisccfg62 liblwres60
> >>> 8 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> >>>
> >>> # apt-get -s upgrade
> >>> Reading package lists... Done
> >>> Building dependency tree
> >>> Reading state information... Done
> >>> The following packages will be upgraded:
> >>>   bind9-host dnsutils libbind9-60 libdns69 libisc62 libisccc60
> >>> libisccfg62 liblwres60
> >>> tex-common
> >>> 9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> >>>
> >>> What's the reason for this?
> 
> Can you check which it is the status of tex-common, is it held by any
> reason? aptitude frontend it is very good to find out such things.
> 
> In anycase, I believe this conversation belongs to debian-user@l.d.o
> and not debian-security@l.d.o

If there it turns out there is actually a problem in aptitude, then
keeping debian-security in the loop is a good thing, so don't worry
about changing mailing list context.  This is a fine place for
discussion.

Best wishes,
Mike


--
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/20110331134459.b9e66b43.michael.s.gilb...@gmail.com

Re: CVE-2010-3847 fixed or not?

[Michael Gilbert]

On Tue, 22 Mar 2011 16:11:33 +0100 Arne Wichmann wrote:

> Hi,
> 
> The situation around CVE-2010-3847 confuses me a bit. The security-tracker
> says CVE-2010-3847 is still open, but the corresponding bug #600667 is
> closed. The same of cource applies for CVE-2011-0536.
> 
> Is there anything I can do to clear things up?

The situation around those three issues is confusing, and I just
haven't had time to figure it out. If you want to research the
advisories, compare to the source code, and report your findings, that
would be helpful.

Best wishes,
Mike


-- 
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/20110322153500.332623ea.michael.s.gilb...@gmail.com

Re: how to apply DSA-2157-1

[Michael Gilbert]

On Sun, 06 Feb 2011 15:50:26 +0100 Edoardo Panfili wrote:

> good morning,
> 
> I am usiong postgres on squeeze.
> 
> Reading  DSA-2157-1 I can see that I must upgrade to 8.4.7-0squeeze1 but 
> I can't find that package using http://www.debian.org/distrib/packages 
> or apt.

Unfortunately, the squeeze packages are currently unavailable.  Due to
the release, that package wasn't uploaded (probably to avoid potential
breakage). It looks like the security team is working on figuring out a
solution for this now, and perhaps there will be another announcement
soon.

Best wishes,
Mike


-- 
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/20110206110523.45a1c17e.michael.s.gilb...@gmail.com

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

[Michael Gilbert]

On Mon, 24 Jan 2011 17:30:31 +0100, Naja Melan wrote:
> We can start with a first step, namely changing the instructions at
> http://debian.org/CD/faq/#verify
> If someone with the authority of changing the debian website would tell me
> that if I wrote a proposition to change those instructions they would
> actually follow it up and see to it that the website will get changed, I am
> prepared to do this. If there is not coming such a green light from the
> debian development I don't have to bother though, because if it isn't going
> to make it to the website, I  might as well stop wasting my time here.

There are no guarantees that your work will be accepted, but that's no
reason not to try.  Like I was trying to convey before, actions speak a
lot louder than words. Implement your ideas and send them to the www
team for review:
http://lists.debian.org/debian-www/

Best wishes,
Mike


-- 
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/20110124113733.5990b9a1.michael.s.gilb...@gmail.com

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

[Michael Gilbert]

On Sun, 23 Jan 2011 20:22:34 -0600 Raphael Geissert wrote:

> Michael Gilbert wrote:
> > There is no need to worry about additional load on the mirrors since
> > the only thing that needs to be verifiable are the checksums
> > themselves, and that could easily be hosted on a centralized https
> > server separate from the mirror system.
> 
> The Debian CDs and the Archive Signing keys can be found at keyring.d.o

Right, I suppose that even the checksums themselves don't need to be
served over https (as long as they're signed by an official key that
can be obtained in a secure manner; via web of trust, over https, or
otherwise).

> Additionally, the archive signing key can be found at:
> https://ftp-master.debian.org/keys.html

The problem from Naja's perspective is that the SPI cert was not issued
by a CA, and for (some) users outside the web of trust that in itself is
a non-starter.  In that sense, an official CA cert would be a modest
improvement in security (even with all of its flaws/shortcomings);
although the ideal solution would be to get the user to become a part of
the web of trust.

Best wishes,
Mike


-- 
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/20110123221136.61cc6950.michael.s.gilb...@gmail.com

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

[Michael Gilbert]

On Sun, Jan 23, 2011 at 12:34 PM, AK wrote:
> Hi all,
>
> a small disclaimer first, I am not affiliated with debian in any way, I
> am, as the original author would have put it a user. I would like to
> play devil's advocate in a few of the quite interesting points that Naja
> raises:
>
> 1) Why is *getting* debian over plain HTTP such a big issue? Assuming
> that even you get a tampered .iso, it is trivial to verify that it is
> not the genuine one, even in using a "broken" hash algorithm such as
> MD5. SSL-enabling all downloads from Debian would have the unfortunate
> side effects of increasing the load on the servers, requiring more
> budget from the Debian team, as well as meaning losing a few mirrors
> around the globe. Personally, I view it as a reasonable risk, provided
> that the end user verifies the .iso image before installing.

There is no need to worry about additional load on the mirrors since
the only thing that needs to be verifiable are the checksums
themselves, and that could easily be hosted on a centralized https
server separate from the mirror system.

> Having said the above, the question is how could someone help by
> donating time/skills to address the points raised by the original poster?

This is one of the downsides of an all-volunteer organization: someone
actually needs to be interested, self-motivated, and willing to work
on the issue at hand.  However, in this case it will be hard for any
non-DD to effect any change directly.  You will need to work with
appropriate teams.

One thing that could be done is to draft up some better wording for
the faq and media download pages, then work with the www team to get
those changes implemented.

Also, a discussion could be started with SPI to see if they are
willing to purchase a CA cert.  That would at least allow users with
implicit trust in the CA system to get a nice fuzzy feeling when they
see the lock icon when downloading checksums.

Anyway, to sum up, things can certainly be improved; it just requires
someone to step up and work with the affected teams to make the
desired changes.

Best wishes,
Mike


-- 
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/aanlktik1ghfan0das1vrp4gn9libqg3jlauayvavw...@mail.gmail.com

Re: Starting point for contributing to debian-security

[Michael Gilbert]

On Mon, 03 Jan 2011 15:05:43 +0100, Yves-Alexis Perez wrote:
> On mar., 2010-12-21 at 22:52 +0100, Yves-Alexis Perez wrote:
> > Starting january, I think I'll be able to dedicate some time to debian
> > security team.
> 
> Ok, so we're now at beginning of january :)
> 
> Is there any starting specific point on which help/time would be needed?
> I know a “call for help” is supposed to happen but in the meantime some
> documentation on what is needed and how would help :)

A good place to start is the security tracker's TODO list [0].  Of
particular interest would be triaging and closing out the remaining
issues from 2008 and 2009.

Also, it would be useful to try to start adopting some of the additional
features applied in Ubuntu [1] but not in Debian.  The hardest part
there is going to be convincing the gcc maintainers to deviate from
upstream defaults.

Best wishes,
Mike

[0] http://security-tracker.debian.org/tracker/status/todo
[1] https://wiki.ubuntu.com/Security/Features


-- 
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/20110103162406.eb3baeda.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA 2134-1] Upcoming changes in advisory format

[Michael Gilbert]

On Sat, 18 Dec 2010 16:47:47 -0800 Vagrant Cascadian wrote:
> will it include a list of affected binary packages (in addition to source
> packages)? 

Just as a point of reference, you can use the debsecan package (or
the security-tracker site [0]) right now to determine whether various
package versions are affected or not.

A feature that I would like to see is a clear machine-parsable
delineation between CVEs that affect stable vs oldstable vs testing vs
unstable. Right now, manual text has to be written to convey this info,
making it impossible automatically parse the advisory for this.

Best wishes,
Mike

[0] http://security-tracker.debian.org


-- 
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/20101219124237.f23b4698.michael.s.gilb...@gmail.com

Re: Bind security announce

[Michael Gilbert]

On Thu, 02 Dec 2010 08:34:40 -1000, Debian security wrote:
> Hello,
> 
> ISC published new versions of their DNS server: bind.
> This version is corrects bug and one security issue (classified as High)
> that impacts the version shipped in Debian Lenny.
> It has been published yeterday and I still can't see any update in the
> security repository.
> Is there any plan to upgrade the bind version in debian to 9.6-ESV-R3
> which correct the bugs?
> 
> https://www.isc.org/software/bind/advisories/cve-2010-3613
> https://www.isc.org/software/bind/advisories/cve-2010-3614

This is the first I've heard of these issues.  You can submit a bug
report against bind9 to encourage the maintainer to start working on a
fix for unstable and a backport for lenny.  It would be even more
helpful if you can extract the patches, apply them, and send a diff
against the current packages.

Mike


-- 
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/20101202140928.24213d1f.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA 2038-3] New pidgin packages fix regression

[Michael Gilbert]

On Mon, 15 Nov 2010 13:59:01 +0100, Gerfried Fuchs wrote:
> Hi!
> 
> * Thijs Kinkhorst  [2010-11-15 13:32:16 CET]:
> > On Mon, November 15, 2010 12:24, Gerfried Fuchs wrote:
> > > * Thijs Kinkhorst  [2010-11-13 20:37:28 CET]:
> > >> Since a few months, Microsoft's servers for MSN have changed the
> > >> protocol,
> > >> making Pidgin non-functional for use with MSN. It is not feasible to
> > >> port
> > >> these changes to the version of Pidgin in Debian Lenny. This update
> > >> formalises that situation by disabling the protocol in the client. Users
> > >> of the MSN protocol are advised to use the version of Pidgin in the
> > >> repositories of www.backports.org.
> > >
> > >  There are several things with this that itch me a fair bit: The most
> > > obvious is that it's now backports.debian.org, not www.backports.org
> > > anymore, which leaves a skew view on the status of the service.
> > 
> > As the (unquoted part of the) text notes, the paragraph you cite is just a
> > fascimile from the original advisory text, nothing more. This explains why
> > recent developments have not been incorporated.
> 
>  Right, just wanted to mention it because it would be nice to change
> that part in case another update from this or any other DSA having the
> old domain name in it would be appreciated.
> 
> > >  Secondly, I can't remember any information exchange between the
> > > security team and the backporters of the package. Especially in the
> > > light of the not-too-far-ago thread on debian-devel about the security
> > > support state on backports where Gilbert left a quite clear opinion (and
> > > non-disputed by other people of the security team) about the state (or
> > > rather, non-state) of security support for backports this is also a fair
> > > bit disturbing.
> > 
> > For this the same goes as for the paragraph above: this relates to
> > information from the original DSA, so it's not a recent development. The
> > maintainer of pidgin provided this advice. It seems reasonable to me that
> > if the maintainer suggests this as an alternative that this can be taken
> > at face value to be a good idea for our users (i.e.: there's commitment to
> > maintain at least that package to a serious level in backports). The
> > advice is clear on the fact that this advice pertains to the pidgin
> > package specifically.
> 
>  Unfortunately the maintainer of pidgin in unstable is not the
> maintainer of pidgin in backports, so there is no commitment in his
> statement, at all. That's the point. There was no discussion with the
> maintainer of pidgin in backports TTBOMK.
> 
> > "Gilbert" is not a part of the security team. I'm unsure why you refer to
> > him only by his last name.
> 
>  Because that's also the IRC nick he uses. Still, he discussed in the
> thread like he speaks for the security team, and like mentioned, there
> was no differentiation brought into the discussion by anyone else that
> would make it clear that he is neither speaking for the team nor that
> his opinion is wrong.
> 
>  Also, you just stated that he is not a part of the security team - that
> unfortunately doesn't get us anywhere though. Were his statements in
> that respect untrue? I would have expected at least a single message
> with respect to some-kind of official statement and not having it stand
> like it was, making it sound that his responses could be seen like the
> view-point of the team.

I didn't mean to sound as if I represented the security team in that
thread. I was simply stating my own viewpoint, which was that if
backports was to continue as an unofficial service, then I personally
was not going to spend any time researching whether issues were present
there. 

Now that it is official, I personally plan to do so as much as I
can. However, the security team has no such requirement. Supporting
backports is a lot of additional work, and perhaps it would be better
to get a dedicated backports-interested team to follow the
secure-testing commits and do the research themselves. Otherwise,
you're asking the security team to sign on to more work (that they
didn't ask for and may not be interested in) without providing them any
additional resources. I don't want to speak for anyone other than
myself, but it looks like it would be very beneficial for the two teams
to have some sort of discussion on roles/responsibilities for backports.

Mike


-- 
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/20101115103746.736459f4.michael.s.gilb...@gmail.com

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Michael Gilbert]

On Thu, 14 Oct 2010 16:39:57 -0500, Jordon Bedwell wrote:
> On Thu, 2010-10-14 at 17:39 -0400, Jordan Metzmeier wrote:
> > There is not only issues of legacy hardware but virtual machines. I
> > signed up for the RHEL 6 beta. Downloaded my copy and fired it up in
> > virtualbox, only to find that it failed to boot, because virtualbox did
> > not support PAE.
> 
> According to Virtualbox Devteam: Virtualbox does support PAE/NX.  I
> don't know where it is, but I found an old ticket from 2007 that is
> marked as 'fixed' and somebody in said ticket mentioned advanced tab.

Yes, there is a non-default "enable PAE/NX" option under settings for
the VM in the virtualbox GUI.  This is rather off-topic at this point.

Best wishes,
Mike


-- 
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/20101014180524.565a58a3.michael.s.gilb...@gmail.com

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Michael Gilbert]

On Mon, 11 Oct 2010 17:18:34 -0500 Marsh Ray wrote:
> > You would need to convince the kernel team that the bigmem kernel
> > should be the default on i386 systems.
> 
> "Please?"

Don't ask this list, ask the kernel team (via bug report and/or
mailing list message).  Note that ubuntu uses some kind of NX emulation
on i386 when its disabled in the bios or unsupported on the cpu, which
may be an option as well here. A patch for that submitted as a kernel
bug would be most effective.

> >> What can be done to at least warn users that the OS is silently
> >> not enforcing the page protections advertised by the CPU?
> >
> > There is the checksec script, which I have packaged, but have yet to
> > get sponsored.  It checks whether various kernel security features
> > are enabled.
> 
> That sounds useful. Do you have a link?

http://trapkit.de/tools/checksec.html

Best wishes,
Mike


-- 
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/20101011192429.ad97c225.michael.s.gilb...@gmail.com

Re: non-executable stack (via PT_GNU_STACK) not being enforced

[Michael Gilbert]

On Mon, 11 Oct 2010 11:50:54 -0500, Marsh Ray wrote:
> On 10/10/2010 12:40 PM, Kees Cook wrote:
> >
> > On Sun, Oct 10, 2010 at 01:35:10PM -0400, Brchk05 wrote:
> >> this means that my CPU supports nx but I do
> >> not have the right type of kernel, i.e., one that uses PAE
> >> addressing, to support enforcement (or is that part Ubuntu
> >> specific).  Does this sound plausible?
> >
> > That is quite likely, yes. If you're running 64bit, you already have
> > PAE mode. If you're running 32bit, you'll need to check your kernel's
> > CONFIG options for PAE. The default for 32bit is _not_ PAE mode, so
> > this is probably what is happening.
> 
> Anyone else perceive this situation as being a bit sub-optimal from the 
> security perspective?

I agree that this is not ideal.

> I'm quite certain there are lots of Debian server admins out there who 
> had assumed that in the year 2010 their operating system is not going to 
> disable the nonexecutable page protection which is built into every 
> modern processor.
> 
> Yes, I have always thought that PAE in general was a kludge, but the NX 
> bit is now a fundamental part of the process integrity provided by the 
> CPU. It's been available in the 2.6 kernel, and shipped in MS Windows, 
> since 2004.
> 
> What can be done to not disable page protections in the default kernel?

You would need to convince the kernel team that the bigmem kernel
should be the default on i386 systems.

> What can be done to at least warn users that the OS is silently not 
> enforcing the page protections advertised by the CPU?

There is the checksec script, which I have packaged, but have yet to
get sponsored.  It checks whether various kernel security features are
enabled.  Other than that, perhaps a debconf warning on kernels without
NX enabled would be useful.

Best wishes,
Mike


-- 
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/20101011134514.0826e6bb.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities

[Michael Gilbert]

On Mon, 11 Oct 2010 10:39:37 -0500, Jordon Bedwell wrote:
> On Mon, 2010-10-11 at 11:15 -0400, Michael Gilbert wrote:
> > I highly doubt that there is anything malicious going on here, and there
> > is always the "Debian does not hide problems" mantra.  The simplest,
> > and most-likely explanation is that it was easier to update to the new
> > upstream, rather than attempt to backport fixes for 11 separate issues.
> 
> Why assume somebody meant something malicious? I implied, that perhaps
> there were smaller security upgrades which would have justified a
> version jump... Really guy.

If there are smaller known security issues that were fixed in the
upload but not mentioned in the DSA, which there aren't, then that
would be a case of hiding problems.  The implication there would be
that security team members are intentionally hiding info about issues,
which they aren't.  However, if that were happening, the only way to
interpret that would be as malicious.

> The serious problem with you assuming I implied that something malicious
> is going on is the fact that we can pull the source that he uploaded to
> Debian directly from Debian and view it.

OK, so do that before making an unfounded claim that there is more to
the issue than you're being told.

Best wishes,
Mike


-- 
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/20101011120415.f21cbba1.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities

[Michael Gilbert]

On Mon, 11 Oct 2010 09:46:04 -0500, Jordon Bedwell wrote:
> On Mon, 2010-10-11 at 10:40 -0400, Michael Gilbert wrote:
> > The problem here appears to be the jump to the new upstream version
> > (1.8.2 to 1.8.13), which has a different dependency set.  New
> > upstreams are usually disallowed in security uploads.  The question
> > is why was that OK in this case, rather than the standard backporting
> > approach?
> 
> Perhaps there was more to this "security problem" than they're telling
> us?

I highly doubt that there is anything malicious going on here, and there
is always the "Debian does not hide problems" mantra.  The simplest,
and most-likely explanation is that it was easier to update to the new
upstream, rather than attempt to backport fixes for 11 separate issues.

Best wishes,
Mike


-- 
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/2010101548.1afb4e4c.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA-2115-2] New moodle packages fix several vulnerabilities

[Michael Gilbert]

On Mon, 11 Oct 2010 14:14:41 +0100, Ian Jackson wrote:
> Florian Weimer writes ("[SECURITY] [DSA-2115-2] New moodle packages fix 
> several vulnerabilities"):
> > DSA-2115-1 introduced a regression because it lacked a dependency on
> > the wwwconfig-common package, leading to installations problems.  This
> > update addresses this issue.  For reference, the text of the original
> > advisory is provided below.
> 
> This is the second recent regression in a security update.  I'm sure
> you'll all agree that this is bad.  It's a shame, because Debian
> security updates have historically had a very good reputation.
> 
> Is there anything that I could do to help with improving things to
> avoid this happening again ?  
> 
> A traditional approach might be to hold a postmortem to try to find
> the chain of events, identify root causes, and make recommendations
> (whether to the Security Team or to others in the project).  Has
> anything like that been done in this case ?

The problem here appears to be the jump to the new upstream version
(1.8.2 to 1.8.13), which has a different dependency set.  New
upstreams are usually disallowed in security uploads.  The question
is why was that OK in this case, rather than the standard backporting
approach?

Best wishes,
Mike


-- 
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/20101011104029.1ac6c88a.michael.s.gilb...@gmail.com

Re: CVE-2009-3555 not addressed in OpenSSL

[Michael Gilbert]

On Tue, 28 Sep 2010 15:04:04 -0500, Marsh Ray wrote:
> On 09/24/2010 02:45 AM, Simon Josefsson wrote:
> > Marsh Ray  writes:
> >
> >> As a long-term Debian user myself, I appeal to Debian's sense of
> >> enlightened self-interest and urge that RFC 5746 support be backported
> >> to stable.
> >
> > FWIW, the latest stable GnuTLS version with RFC 5746 support is not even
> > in testing, so it won't be part of even the next stable.  It may be too
> > late for that in the release cycle though...
> 
> But that's a choice made by Debian. Call it release policy, procedure, 
> or whatever, Debian cannot use the existence of its own bureaucracy as a 
> justification for wrong action (or inaction).
> 
> As you certainly know Simon, great effort has been expended by many 
> people over the course of the last year to develop and deploy 
> industry-wide a backwards-compatible protocol fix in record time. To 
> this end, minor version updates and source patches to all major 
> open-source implementations were provided to library users and distros. 
> Under these circumstances, I contend that it is wrong for Debian to 
> withhold these security fixes from its installed base.
> 
> Web browsers are now warning users about unpatched servers. Server 
> admins who run Debian are left without a packaged solution. 
> Consequently, their users are unable to configure their client 
> applications to strict (more secure) mode and client applications must 
> ship with the less secure default settings.
> 
> These facts remain:
> 
> Opera has implemented the correct fix for this security bug,
> Microsoft has implemented the correct fix for this security bug,
> Mozilla has implemented the correct fix for this security bug,
> OpenSSL has implemented the correct fix for this security bug,
> IBM Java has implemented the correct fix for this security bug,
> GNUTLS has implemented the correct fix for this security bug,
> Google has implemented the correct fix for this security bug,
> RedHat has implemented the correct fix for this security bug,
> Ubuntu has implemented the correct fix for this security bug,
> ...yet...
> Debian has not implemented the correct fix for this security bug.

Debian, being a volunteer organization, has it's upsides and
downsides.  The downside here being without an active volunteer
interested in this problem, nothing has happened.

What is needed here is someone to step up to the plate: file some bugs;
try to find the patches; backport and test them; etc.  Bottom line,
a little work and communication with maintainers of the affected
packages would go a long way toward resolving this.

Best wishes,
Mike


-- 
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/20100929165222.34d3e611.michael.s.gilb...@gmail.com



-- 
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/.4ca43...@fliegl.com

Re: CVE-2009-3555 not addressed in OpenSSL

[Michael Gilbert]

On Wed, 29 Sep 2010 14:13:37 -0700, Kyle Bader wrote:
> > Debian, being a volunteer organization, has it's upsides and
> > downsides.  The downside here being without an active volunteer
> > interested in this problem, nothing has happened.
> >
> > What is needed here is someone to step up to the plate: file some bugs;
> > try to find the patches; backport and test them; etc.  Bottom line,
> > a little work and communication with maintainers of the affected
> > packages would go a long way toward resolving this.
> 
> That was my initial goal in initiating this conversation.  I provided
> a link to the patches already:
> 
> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/jaunty/openssl/jaunty-proposed/revision/34
> 
> I installed the jaunty package on my lenny machines and the ff error
> console warning is gone:
> 
> https://debian-lenny.badercom.net/
> 
> It appears to work but whenever a package as critical as openssl is
> modified it's important to have upstream take a look to make sure
> everything looks good.  Ubuntu may or may not have done this, I
> haven't done the leg work to figure that out but it looks like that
> could be the next step.  If I/we/whoever can verify this or gain the
> blessing of upstream would you consider updating the package Kurt if I
> also coordinate this with the Debian apache and nginx packagers?

I could have sworn that renegotion in lenny's openssl was disabled.
But according to the changelog, that looks to not be the case [0].
Based on that, I agree that a DSA should be issued.

Mike

[0]
http://packages.debian.org/changelogs/pool/main/o/openssl/openssl_0.9.8g-15+lenny8/changelog


--
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/20100929172338.fe2db2e5.michael.s.gilb...@gmail.com

Re: CVE-2009-3555 not addressed in OpenSSL

[Michael Gilbert]

On Wed, Sep 29, 2010 at 4:57 PM, Jordon Bedwell wrote:
> There is a bug against openssl and mod_ssl for apache already they simply
> just block renegotiation (unless they did a better patch later that I don't
> recall seeing) and one was challenged (if I remember right openssl) because
> it was missing something. Personally I had assumed Debian of all people
> would be on  the ball with this so I never double backed to check and see if
> they patched it properly but I remember everything just being block block
> block and not fix fix fix for real.

I'm not really sure what the remaining problems are (just gnutls
lacking support for RFC 5746?).  Whoever knows of what those problems
are, please file bugs.

Thanks,
Mike


--
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/aanlktimkezu1vslgv8weuuydx2+vcygyaehvxh19z...@mail.gmail.com

Re: CVE-2009-3555 not addressed in OpenSSL

[Michael Gilbert]

On Tue, 28 Sep 2010 15:04:04 -0500, Marsh Ray wrote:
> On 09/24/2010 02:45 AM, Simon Josefsson wrote:
> > Marsh Ray  writes:
> >
> >> As a long-term Debian user myself, I appeal to Debian's sense of
> >> enlightened self-interest and urge that RFC 5746 support be backported
> >> to stable.
> >
> > FWIW, the latest stable GnuTLS version with RFC 5746 support is not even
> > in testing, so it won't be part of even the next stable.  It may be too
> > late for that in the release cycle though...
> 
> But that's a choice made by Debian. Call it release policy, procedure, 
> or whatever, Debian cannot use the existence of its own bureaucracy as a 
> justification for wrong action (or inaction).
> 
> As you certainly know Simon, great effort has been expended by many 
> people over the course of the last year to develop and deploy 
> industry-wide a backwards-compatible protocol fix in record time. To 
> this end, minor version updates and source patches to all major 
> open-source implementations were provided to library users and distros. 
> Under these circumstances, I contend that it is wrong for Debian to 
> withhold these security fixes from its installed base.
> 
> Web browsers are now warning users about unpatched servers. Server 
> admins who run Debian are left without a packaged solution. 
> Consequently, their users are unable to configure their client 
> applications to strict (more secure) mode and client applications must 
> ship with the less secure default settings.
> 
> These facts remain:
> 
> Opera has implemented the correct fix for this security bug,
> Microsoft has implemented the correct fix for this security bug,
> Mozilla has implemented the correct fix for this security bug,
> OpenSSL has implemented the correct fix for this security bug,
> IBM Java has implemented the correct fix for this security bug,
> GNUTLS has implemented the correct fix for this security bug,
> Google has implemented the correct fix for this security bug,
> RedHat has implemented the correct fix for this security bug,
> Ubuntu has implemented the correct fix for this security bug,
> ...yet...
> Debian has not implemented the correct fix for this security bug.

Debian, being a volunteer organization, has it's upsides and
downsides.  The downside here being without an active volunteer
interested in this problem, nothing has happened.

What is needed here is someone to step up to the plate: file some bugs;
try to find the patches; backport and test them; etc.  Bottom line,
a little work and communication with maintainers of the affected
packages would go a long way toward resolving this.

Best wishes,
Mike


-- 
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/20100929165222.34d3e611.michael.s.gilb...@gmail.com

Re: [SECURITY] [DSA 2110-1] New Linux 2.6.26 packages fix several issues

[Michael Gilbert]

On Fri, 17 Sep 2010 11:02:13 -0700, Kyle Bader wrote:
> > Package        : linux-2.6
> > Vulnerability  : privilege escalation/denial of service/information leak
> > Problem type   : local
> > Debian-specific: no
> > CVE Id(s)      : CVE-2010-2492 CVE-2010-2954 CVE-2010-3078 CVE-2010-3080
> >                 CVE-2010-3081
> 
> What about CVE-2010-3301?
> 
> http://seclists.org/oss-sec/2010/q3/369

>From the second line of Eugene's announcement:

"Introduced in v2.6.27-rc1 via commit d4d67150."

Lenny has a 2.6.26 kernel, so it isn't affected.

> Coming soon to a repo near you? :D

Not needed.

Best wishes,
Mike


--
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/20100917141914.186b31c6.michael.s.gilb...@gmail.com

Re: [Fwd: Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities]

[Michael Gilbert]

On Wed, 10 Mar 2010 17:21:45 -0500, Daniel Kahn Gillmor wrote:
> We recommend that you upgrade your kvm package.  If your system is
> currently using a kvm-modules package built from previous versions of
> the kvm-source package, we recommend that you upgrade your kvm-source
> package, re-build a new kvm-modules package and install it.  You should
> subsequently unload the old kvm modules from your kernel and reload the
> newly built kernel modules.  The simplest way to accomplish this kernel
> module unload/reload is a system restart.

a restart is (almost) never the answer. i think a better approach would
be the following simple instructions

 if you have previously installed the kvm modules on your system, they
 need to be refreshed following an upgrade of your kvm packages.  please
 execute the following commands as root after the new packages are
 installed:

  # m-a a-i kvm-source
  # modprobe kvm

mike


-- 
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/20100310174410.1e99b2e5.michael.s.gilb...@gmail.com

Re: Linux 2.6 update for Etch

[Michael Gilbert]

On Thu, 18 Feb 2010 14:53:14 +0200 Peter Pentchev wrote:

> Hi,
> 
> First of all, apologies if this is sent to the wrong list, or if this
> information is already available somewhere; also, I'm aware that
> security support for Debian Etch ended a couple of days ago.
> 
> In the recent DSA-1996-1 for the linux-2.6 package vulnerabilities,
> there was the following sentence:
> 
>   For the oldstable distribution (etch), these problems, where
>   applicable, will be fixed in updates to linux-2.6 and linux-2.6.24.
> 
> Now, since we several servers that we are currently in the process of
> migrating to Lenny, but the migration will not be complete for at
> least several more weeks (and yes, I know this is our own fault :),
> I'd just like to ask if there's any timeframe on when the Etch
> updates for the linux-2.6 package shall be released - without meaning
> to hurry anybody or to be pushy or something; I'm quite aware of
> all the work that goes into maintaining security updates across
> multiple versions of multiple packages on old distributions,
> and the security team has my sincere thanks and condolences for all
> the work they have to do so we can sleep soundly :)
> 
> Or maybe I'm missing something and the Etch update has already been
> released?  But the only updated package I can see at
> http://security.debian.org/pool/updates/main/l/ is the "latest" one -
> linux-latest-2.6_6etch3; but from what I can see, it builds
> the linux-image-2.6-amd64_2.6.18+6etch3 package, which just depends on
> linux-image-2.6.18-6-amd64 (the actual kernel), and the actual kernel
> at http://security.debian.org/pool/updates/main/l/linux-2.6/ seems
> to still be at version 2.6.18.dfsg.1-26etch1 from November 5, 2009.
> 
> Am I missing something, or is it just a question of manpower and time?
> If the latter, sorry if this mail comes through as pushy - it's really
> not meant to be!
> 
> Again, thanks to the security team for all their hard work!
> Please CC me on replies, since I'm not subscribed to this list.

you didn't miss anything.  the update is in the works, and will be
released with the next etch point release (as seen in some other mailing
list; which one, i don't remember). the release team would be a better
place to ask about when that is going to happen, but if they haven't
announced anything publicly yet, then they probably have yet to set a
date.

mike


-- 
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/20100218215043.ac95e422.michael.s.gilb...@gmail.com

Re: CVE-2004-0230 RST DoS vulnerability in Lenny?

[Michael Gilbert]

On Thu, 11 Feb 2010 14:55:15 -0600 JW wrote:

> Recently we've had a scanning vendor tell us our Debian Lenny 5.0.3 is 
> vulnerable to CVE-2004-0230:
> 
> TCP/IP Sequence Prediction Blind Reset Spoofing DoS
> 
> "It may be possible to send spoofed RST packets to the remote system."
> 
> " . . . vulnerable to a sequence number
> approximation bug, which may allow an attacker to send
> spoofed RST packets to the remote host and close established
> connections . . . "
> 
> When I tried to look up info about it - one pages lists "Linux" as vulnerable 
> (with no additional information) and I am not able to find anything about 
> Debian's status or relationship to it except possibly for 
> http://www.mail-archive.com/secure-testing-comm...@lists.alioth.debian.org/msg01390.html
>  
> which possibly indicates it's fixed, or someone tried to fix it in 2005.
> 
> Does anyone know anything about this? I'm needing some kind of fix or 
> work-around so I can satisfy the scan vendor. 

It looks to be a known issue, which has been determined to be
unimportant in pretty much all circumstances (i.e. even if it is
successful, it just causes a disconnect, which isn't even an issue
since most configurations will just automatically restablish). 

So unless you are doing BGP (Border Gateway Protocol) where disconnects
do have a major impact, I would seriously question the value you are
getting from a scan vendor who makes you worry about issues without
understanding the problem themselves first.

Mike


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

Re: UNS: Debian 4.0 Upgrade Path

[Michael Gilbert]

On Thu, 21 Jan 2010 18:13:03 +, Robert Lemmen wrote:
> On Thu, Jan 21, 2010 at 11:20:28AM -0500, Noah Meyerhans wrote:
> > In general, skipping major versions has never been supported.  An
> > upgrade from etch to squeeze should always involve a short stop in
> > lenny.
> 
> of course, but doing these two upgrades one after another on a couple of
> machines is still easier than doing the first one on all the machines,
> and then the second one a few months later. especially if you factor in
> paperwork and explanations of changes that might be required.
> 
> i fully agree with thiemo, having the security support of release N run
> out when the security support for N+2 starts would be *very* cool, then
> people could skip releases if the cost/risk of upgrading is high and the
> need for brand new software is low.

i agree that longer support for old releases would be wonderful, but
that would mean at times providing full support for three concurrent
releases (oldstable, stable, and testing).  

it already seems hard enough with the current level of manpower to
support two releases at the same time let alone three.  it may be
doable, but the security team would need more volunteers (particularly
those interested in doing the work to keep oldstable supported).

mike


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

Re: is 2.6.26-19lenny1 legit?

[Michael Gilbert]

On Fri, 23 Oct 2009 11:04:03 -0400, Tom Vier wrote:
> I don't seen any annoucement on security-announce or on security.debian.org!
> Are these packages legit?
> 
> linux-headers-2.6.26-2-amd64_2.6.26-19lenny1_amd64.deb
> linux-headers-2.6.26-2-common_2.6.26-19lenny1_amd64.deb
> linux-libc-dev_2.6.26-19lenny1_amd64.deb
> linux-image-2.6.26-2-amd64_2.6.26-19lenny1_amd64.deb
> 
> linux-image-2.6.26-2-686_2.6.26-19lenny1_i386.deb
> linux-libc-dev_2.6.26-19lenny1_i386.deb

yes, these updates are legitimate.  i saw some recent activity working
on the security announcement for this, but for some reason it has not
gone out yet.  maybe an oversight?

mike


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

Re: Xpdf Integer overflow

[Michael Gilbert]

On Fri, 16 Oct 2009 20:15:50 +0300, Henri Salo wrote:
> Is update for Xpdf-vulnerability coming soon for this issue:
> 
> 

this issue was not disclosed responsibly, and we have just started
tracking the problem.  you can follow bug #551287.

mike


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

Re: [SECURITY] [DSA 1885-1] New xulrunner packages fix several vulnerabilities

[Michael Gilbert]

On Mon, 14 Sep 2009 22:41:23 +0200, Michel Messerschmidt wrote:
> On Mon, Sep 14, 2009 at 07:05:35PM +0200, Moritz Muehlenhoff wrote:
> > For the experimental distribution, these problems have been fixed in
> > version 1.9.1.3-1.
> 
> It seems the update is not yet available for i386 because the build failed
> (http://experimental.debian.net/new/package.php?suite=experimental&p=xulrunner&a=i386)

a build problem like this is not (and should not be) cause to change
(or delay) the DSA (especially since experimental is not technically a
security-supported release).

if your goal is just to inform the developer of this problem, a bug
report would be a lot more useful.

mike


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

Fixes for gaim/pidgin vulnerabilities?

[Michael Gilbert]

Ubuntu [1] has recently released fixes for CVE-2008-2955,
CVE-2008-2957, and CVE-2008-3532 in gaim/pidgin.  Can we expect to see
these fixes released for Etch soon?

Also note that Ubuntu seems to have missed CVE-2008-2956 [2], which
also applies to gaim/pidgin.  The problem has not yet been fixed in
any of the Debian archives, which may explain why they did not include
a patch for this one.

Thanks for working to keep Debian secure.

[1] http://www.ubuntu.com/usn/USN-675-1
[2] http://security-tracker.debian.net/tracker/CVE-2008-2956


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

Fixes for HPLIP vulnerabilities in Etch?

[Michael Gilbert]

Now that ubuntu [1] has released fixes for CVE-2008-2940 and
CVE-2008-2941 in HPLIP, can we expect to see the same for Etch soon?

Thanks for working to keep Debian secure.

[1] http://www.ubuntu.com/usn/USN-674-1


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

re: CVE-2008-0595: possible DoS in dbus

[Michael Gilbert]

retitle 501443 dbus: CVE-2008-3834, possible DoS
thank you

hello, now that ubuntu has released fixes for this issue [1], can we
hope to see the same action from debian soon?

note also that the original report had the wrong CVE in the title
(which i've fixed) and has a different wrong CVE in one of the links
in the message.  the correct CVE link is [2].

[1] http://www.ubuntu.com/usn/usn-653-1
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3834


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

Re: Bug#496851: yelp: does not correctly handle format strings for certain error messages

[Michael Gilbert]

>> what about a getting a fix for this issue into stable?
>
>  it doesn't affect stable

ok, can someone update the tracker [1] to reflect that this issue does
not effect etch (yelp 2.14) and sarge (yelp 2.6)?

[1] http://security-tracker.debian.net/tracker/CVE-2008-3533


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

Re: Bug#496851: yelp: does not correctly handle format strings for certain error messages

[Michael Gilbert]

notfound 496851 2.22-1-6
thank you

what about a getting a fix for this issue into stable?

> yelp (2.22.1-4) unstable; urgency=high
>
>  * SECURITY: New patch, 60_format-string, fixes format string vulnerability;
>bump urgency to high; CVE-2008-3533; GNOME #546364; from SVN r3173;
>LP: #254860.
>
>> Package: yelp
>> Version: 2.22.1-6
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>>
>> yelp is vulnerable to attacks via badly formatted strings for certain error
>> messages.  ubuntu recently released a fix for this problem [1].  the issue
>> is described as:
>>
>>   Aaron Grattafiori discovered that the Gnome Help Viewer did not handle
>>   format strings correctly when displaying certain error messages.  If a
>>   user were tricked into opening a specially crafted URI, a remote attacker
>>   could execute arbitrary code with user privileges.
>>
>> this may or may not be related to CVE-2008-3533 [2].  this should be
>> considered a high-urgency vulnerability since it allows remote attackers
>> to exectute arbitrary code.
>>
>> thank you for the hard work.
>>
>> [1] http://www.ubuntu.com/usn/usn-638-1
>> [2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3533


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

unfixed linux 2.6.24 and python vulnerabilities

[Michael Gilbert]

now that ubuntu has released an updated 2.6.24 kernel [1] today that
fixes a couple CVEs that are as-yet unfixed in debian, and as of 25
days ago had released updates to python to fix quite a few CVEs [2]
that are also as-yet unfixed in debian, can we expect to see some
updates for these packages enter debian stable any time soon?

shouldn't debian (upstream) be ahead ubuntu (downstream) in terms of
pushing out security updates?  or at least be reactive enough to take
ubuntu's changes and release updated packages within a day (or at most
two)?  is there any way that the two security teams could do better at
collaborating (coordinate releases to reduce exposure time for the
opposing distro)?

[1] http://www.ubuntu.com/usn/usn-637-1
[2] http://www.ubuntu.com/usn/usn-632-1


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

Re: Bug#492806: libavformat52: does not handle STR file demuxing (CVE-2008-3162)

[Michael Gilbert]

>> Package: libavformat52
>> Version: 0.svn20080206-11
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>>
>> ubuntu just updated their libavformat packages to patch a problem with
>> STR file demuxing [1].  does this problem apply to debian as well?  the
>> CVE number is CVE-2008-3162 [2].
>>
>> [1] http://www.ubuntu.com/usn/usn-630-1
>> [2] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3162

> Thanks for your report but this bug is a clear dupe of #489965.

ok, i appologize, i did a quick scan of bugs in libavformat, and
somehow missed this.

there has not been a DSA to fix this problem in stable.  is the
libavformat0d package vulnerable there?  and if so, why isn't the
issue being tracked [1]?

[1] http://security-tracker.debian.net/tracker/status/release/stable


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

Re: [SECURITY] [DSA 1615-1] New xulrunner packages fix several vulnerabilities

[Michael Gilbert]

> The correct place to report this is [EMAIL PROTECTED]
> Just forward one of the mails and ask that they remove him. I
> just did that, so he should be gone shortly.

wouldn't it be better to send this person a warning?  i'm sure it was
just an honest mistake.  it seems rather harsh to purge them from the
mailing list without giving them a fair chance to remedy their
mistake.


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

Re: Status of CVE-2008-1615 in stable?

[Michael Gilbert]

On 5/23/08, dann frazier wrote:
> On Thu, May 22, 2008 at 11:23:36PM -0400, Michael Gilbert wrote:
>> Looks like redhat recently released updates [1] that fix the
>> high-severity vulnerability described by CVE-2008-1615 [2].  Will a
>> similar fix be pushed out to debian etch any time soon?
>
> yes, a patch for this is queued for the next update which I expect to
> be released this weekend.

cool.  thanks for the hard work.


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

Status of CVE-2008-1615 in stable?

[Michael Gilbert]

Looks like redhat recently released updates [1] that fix the
high-severity vulnerability described by CVE-2008-1615 [2].  Will a
similar fix be pushed out to debian etch any time soon?

It looks like it should be pretty straightforward since it is a
one-line patch [2].

[1] http://rhn.redhat.com/errata/RHSA-2008-027
[2] http://security-tracker.debian.net/tracker/CVE-2008-16155.html
[3] https://bugzilla.redhat.com/attachment.cgi?id=294062


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