Backporting a security fix for e2fsprogs to Stable

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Backporting a security fix for e2fsprogs to Stable

Theodore Y. Ts'o
Hi, I just released e2fsprogs v1.45.4 (upstream and for Debian
unstable) which among other things, contains a fix[1] for
CVE-2019-5094 / TALOS-2019-0887.  I imagine Talos will be doing a full
disclosure with a proof-of-concept exploit within the next few days.

[1] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint&id=8dbe7b475ec5e91ed767239f0e85880f416fc384

The impact of this bug is that if an attacker can tricker the system
into running e2fsck on an untrustworthy file system as root, a
maliciously crafted file system could result in a buffer overflow that
can result in arbitrary userspace memory modification.  Hence,
weaponizing this vulnerability so allowing the attacker to run code as
whatever user ran e2fsck should be fairly simple.

What's the procedure with respect to getting this backported to the
vesion of e2fsprogs in Debian Stable?  Will you do it, or should I do
the backport?  I'm happy to create the backport, but then what's the
best way of getting this into Stable as efficiently as possible?

Thanks,

                                                - Ted

Reply | Threaded
Open this post in threaded view
|

Re: Backporting a security fix for e2fsprogs to Stable

Salvatore Bonaccorso-4
Hi Ted,

[FTR, this is on the security public discussion list, if you need to
contact the security team directly, you might use [hidden email] or
security@d..o]

On Mon, Sep 23, 2019 at 07:42:02PM -0400, Theodore Y. Ts'o wrote:

> Hi, I just released e2fsprogs v1.45.4 (upstream and for Debian
> unstable) which among other things, contains a fix[1] for
> CVE-2019-5094 / TALOS-2019-0887.  I imagine Talos will be doing a full
> disclosure with a proof-of-concept exploit within the next few days.
>
> [1] https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint&id=8dbe7b475ec5e91ed767239f0e85880f416fc384
>
> The impact of this bug is that if an attacker can tricker the system
> into running e2fsck on an untrustworthy file system as root, a
> maliciously crafted file system could result in a buffer overflow that
> can result in arbitrary userspace memory modification.  Hence,
> weaponizing this vulnerability so allowing the attacker to run code as
> whatever user ran e2fsck should be fairly simple.
>
> What's the procedure with respect to getting this backported to the
> vesion of e2fsprogs in Debian Stable?  Will you do it, or should I do
> the backport?  I'm happy to create the backport, but then what's the
> best way of getting this into Stable as efficiently as possible?

We can release a DSA for this issue. Can you prepare proposed updates
for buster-security (and stretch-security, assuming it is affected as
well)?

Speaking of procedure, depending on if an issue warrants a DSA, you
mgiht be redirected to the stable release managers for inclusion in a
point release. There are some guidelines as well in the dev-ref about
uploads for stable/oldstable (both for specifics on point releases and
security-updates via security.d.o). Usually please do send proposed
debdiffs then for a short review/ack for the upload to the security
team before uploading to security master.

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#upload-stable
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#s5.6.4
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security
and
https://www.debian.org/security/faq

Does this helps?

Regards,
Salvatore