p5->p3 mass change

It doesn't strike me as a being a particularly terrific vulnerability. For one thing, you should read untrusted patches before you apply them. For another, if you fail to do so and apply an untrusted patch without reviewing it, then the code of whatever project you're working on is potentially compromised, which is much worse than an arbitrary file being created on your system, methinks.

Nevertheless, it would be nice to have this fixed, for the simple reason that I can't think of a legitimate use of this "feature".

I can't see any reply on the bug-patch list, and also no entry in the upstream patch bugtracker, and no fix in the upstream repository. I'll look into it next week, unless upstream reacts by then.

No problem... I put it on the list of "planned updates". You can fix it later as part of another more serious issue.

Would be nice to have 11.4 fixed.

Re: [oss-security] CVE request: patch directory traversal flaw
 Von: Vasiliy Kulikov <segoon@openwall.com>
 An: oss-security@lists.openwall.com
 Kopie: coley <coley@mitre.org>
 
The patch of Jim Meyering introduces interdiff regression:

$ interdiff -z john-1.7.6-jumbo-9.diff.gz john-1.7.6-jumbo-10.diff.gz
patch: **** rejecting absolute target file name: /tmp/.private/genie/interdiff-1.7yovIC
interdiff: Error applying patch1 to reconstructed file

interdiff creates a patch with absolute filenames, but doesn't pass the
target filename as an argument to patch.

It is fixed in the latest upstream version 0.3.2.  The fix itself is as
follows:

--- patchutils-0.3.1.orig/src/interdiff.c       2011-02-18 17:57:05.000000000 +0300
+++ patchutils-0.3.1/src/interdiff.c    2011-02-18 17:57:24.000000000 +0300
@@ -808,7 +808,7 @@ apply_patch (FILE *patch, const char *fi
        FILE *w;
 
        w = xpipe(PATCH, &child, "w", PATCH,
-                 reverted ? "-Rsp0" : "-sp0", NULL);
+                 reverted ? "-Rsp0" : "-sp0", file, NULL);
 
        fprintf (w, "--- %s\n+++ %s\n", file, file);
        line = NULL;
--


Thanks,

-- 
Vasiliy

Fix for this bug is upstream:
http://git.savannah.gnu.org/cgit/patch.git/commit/?id=685a78b6052f4df6eac6d625a545cfb54a6ac0e1

As far as I can see, the interdiff regression is fixed in devel:tools, but the changes haven't been pushed to openSUSE:Factory yet, even though they are almost 2 months old. Stefan, can you please get them there?

As there is a dependency between the two fixes, I presume I should add:
Conflicts: patchutils < 0.3.2
in patch.spec, right?

BTW, shouldn't package patchutils depend on /usr/bin/patch?

(In reply to comment #6)
> Fix for this bug is upstream:
> http://git.savannah.gnu.org/cgit/patch.git/commit/?id=685a78b6052f4df6eac6d625a545cfb54a6ac0e1
> 
> As far as I can see, the interdiff regression is fixed in devel:tools, but the
> changes haven't been pushed to openSUSE:Factory yet, even though they are
> almost 2 months old. Stefan, can you please get them there?

done (SR #65918)

> As there is a dependency between the two fixes, I presume I should add:
> Conflicts: patchutils < 0.3.2
> in patch.spec, right?

This would make sense, yes.

> BTW, shouldn't package patchutils depend on /usr/bin/patch?

If it requires patch, yes. Does it?

(In reply to comment #7)
> > BTW, shouldn't package patchutils depend on /usr/bin/patch?
> 
> If it requires patch, yes. Does it?

If not, then how could there be a dependency between the two fixes?

Looking at the code (search for "xpipe"), interdiff uses both "diff" and "patch", and rediff uses "diff". So patchutils should depend on both /usr/bin/patch and /usr/bin/diff (or their respective packages, I don't know which approach is preferred.)

You're right. But why not just depend on the patch package?

patch and diff packages. Yes, this would be perfectly fine with me.

Ok. Let's add patch and diffutils to Requires of patchutils.

Now in devel:tools/patchutils and submitrquest for openSUSE:Factory (SR #65947).

Thanks. Meanwhile I have packaged patch version 2.6.1.116 (i.e. a development snapshot) in devel:tools, which includes a fix for CVE-2010-4651. I'll submit it for inclusion into openSUSE:Factory as soon as patchutils is up-to-date there.

Fix is in openSUSE:Factory now.

After discussing this with my manager, I am now almost convinced that this is serious enough to warrant a maintenance update in all our released products. Thomas, Marcus, what do you think?

One issue we have is that the fix breaks interdiff from the patchutils package, so we would have to update both the patch and patchutils packages for this maintenance update. I am worried about how we can guarantee that an old version of patchutils won't be used with a new version of patch. In openSUSE:Factory I declared a conflict between the new patch package and patchutils < 0.3.2, but we aren't going to do a version update of patchutils in released products, so this approach won't work there. Is there a solution to this problem, or do we just hope that users don't cherry-pick which updates they install?

(In reply to comment #14)
> Fix is in openSUSE:Factory now.
> 
> After discussing this with my manager, I am now almost convinced that this is
> serious enough to warrant a maintenance update in all our released products.
> Thomas, Marcus, what do you think?

AFIACT it's low severity. Do you have arguments for rating it higer?

> One issue we have is that the fix breaks interdiff from the patchutils package,
> so we would have to update both the patch and patchutils packages for this
> maintenance update. I am worried about how we can guarantee that an old version
> of patchutils won't be used with a new version of patch. In openSUSE:Factory I
> declared a conflict between the new patch package and patchutils < 0.3.2, but
> we aren't going to do a version update of patchutils in released products, so
> this approach won't work there. Is there a solution to this problem, or do we
> just hope that users don't cherry-pick which updates they install?

We can determine the exact version-release of the patchutils
versions on each product to install specific conflicts.

(In reply to comment #15)
> AFIACT it's low severity. Do you have arguments for rating it higher?

My manager and myself discussed two scenarios which could be worrying.

First scenario is a patch touching /etc/passwd and /etc/shadow, if root is running the patch utility. Parts of these files can be guessed by the attacker if he/she knows which Linux distribution the target user is running, so it is possible to craft the patch contents suitably to add one line in each file.

Obviously this can be ruled out by declaring that root should never ever run patch. But aren't we doing exactly this in the build service?

Second scenario is a patch touching files in a user's home. When you send a patch by mail to someone, you can often guess his login and thus the value of $HOME. So it is possible to attempt to create arbitrary configuration files in the target user's home. This would go unnoticed if the user applies patches with the --quiet option (or through quilt with "quilt push -q" or any similar patch series manipulation tool).

This one can be ruled out by declaring that you should never apply a patch without reviewing it, especially when received from someone you don't trust, and especially not in quiet mode.

If you aren't convinced that any of the above is worth worrying, then we're done.

(In reply to comment #16)
> (In reply to comment #15)
> > AFIACT it's low severity. Do you have arguments for rating it higher?
> 
> My manager and myself discussed two scenarios which could be worrying.
> 
> First scenario is a patch touching /etc/passwd and /etc/shadow, if root is
> running the patch utility. Parts of these files can be guessed by the attacker
> if he/she knows which Linux distribution the target user is running, so it is
> possible to craft the patch contents suitably to add one line in each file.
> 
> Obviously this can be ruled out by declaring that root should never ever run
> patch. But aren't we doing exactly this in the build service?

Fortunately not :-)

> Second scenario is a patch touching files in a user's home. When you send a
> patch by mail to someone, you can often guess his login and thus the value of
> $HOME. So it is possible to attempt to create arbitrary configuration files in
> the target user's home. This would go unnoticed if the user applies patches
> with the --quiet option (or through quilt with "quilt push -q" or any similar
> patch series manipulation tool).
> 
> This one can be ruled out by declaring that you should never apply a patch
> without reviewing it, especially when received from someone you don't trust,
> and especially not in quiet mode.
> 
> If you aren't convinced that any of the above is worth worrying, then we're
> done.

I don't think it's bad enough to warrant an update for SLE. That's why I put it
on the list of planned updates. IOW we may fix it if some other reason
justifies an update of the package anyays.

Fine with me.

SUSE-SU-2018:1162-1: An update that solves four vulnerabilities and has one errata is now available.

Category: security (important)
Bug References: 1059698,1080918,1088420,662957,914891
CVE References: CVE-2010-4651,CVE-2014-9637,CVE-2016-10713,CVE-2018-1000156
Sources used:
SUSE Linux Enterprise Server 11-SP4 (src):    patch-2.5.9-252.22.7.1
SUSE Linux Enterprise Server 11-SP3-LTSS (src):    patch-2.5.9-252.22.7.1
SUSE Linux Enterprise Point of Sale 11-SP3 (src):    patch-2.5.9-252.22.7.1
SUSE Linux Enterprise Debuginfo 11-SP4 (src):    patch-2.5.9-252.22.7.1
SUSE Linux Enterprise Debuginfo 11-SP3 (src):    patch-2.5.9-252.22.7.1

The fix for this bug causes some not-so-bad patches to be rejected by patch, see bug #1093615.