On 05/23/2013 13:02, Stefan Esser wrote:
Quoting from the patch(1) man page:
[...]
patch will examine either the “old” and
    “new” file names or, for a non-context diff, the “index” file name,
    and choose the file name with the fewest path components, the short-
    est basename, and the shortest total file name length (in that
    order).

I did read that, got confused, and decided to put off further attempts to 
understand the program--manpage connection.

Your patch file example has the following file information:

--- texi2html.pl        2012-07-09 10:54:41.000000000 +0200
+++ /usr/local/bin/texi2html    2012-07-09 10:53:16.000000000 +0200

Patch will modify "texi2html.pl" in the work directory. The
other file name (/usr/local/bin/texi2html) is ignored.

So, there is no problem with this patch, if patch works as
advertised.

In that case, I see no security issues (assuming I didn't miss anything): all 
patch files (containing at least 1 absolute path, excluding /dev/null) would 
point the patch program to the work directory, provided that a 
manpage-conforming program is used.

Some patch files refer to target files in the /tmp directory.
Theoretically, this means that malicious regular users are able to
fiddle with the patching process: by creating the target files in the
/tmp directory, they are able to silently cause patches to apply to
bogus files in the /tmp directory instead of the intended files in the
port's work directory. In the extreme case, a malicious user could cause
ports to be built without certain security patches. The user could also
try a symlink attack.

But it is highly unlikely, that the chunk will apply cleanly, and
thus patch will abort without changing the bogus target file, in
most cases.

In which case a reject file will be written to /tmp/<insert_target_file_here>.rej, 
which will be -- perhaps only at the right time, as a race condition -- a symlink to 
/etc/<insert_important_file_here>. Unfortunately, my brief attempt at making this 
work failed.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to