Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SECURITY] Processing fixup entries may follow symbolic links #1566

Closed
mmatuska opened this issue Aug 22, 2021 · 4 comments
Closed

[SECURITY] Processing fixup entries may follow symbolic links #1566

mmatuska opened this issue Aug 22, 2021 · 4 comments

Comments

@mmatuska
Copy link
Member

Some modes, times, ACLs and file flags especially on directories are set on archive_write_close() time. An archive can contain multiple entries with the same path. If a directory entry is marked for post-processing and a symlink entry with the same path "replaces" the directory with the symlink, the "fixup" postprocessing may alter the link target instead of the file itself.
mmatuska added a commit to mmatuska/libarchive that referenced this issue Aug 22, 2021
@mmatuska
Do not follow symlinks when processing fixup list
69b34c0 
Use lchmod() instead of chmod() and tell the remaining functions that the
real file to be modified is a symbolic link.

Fixes libarchive#1566
mmatuska added a commit to mmatuska/libarchive that referenced this issue Aug 27, 2021
@mmatuska
Fix following symlinks when processing the fixup list
c9619dd 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing the correct flags to open() and
if it fails to check directory via lstat().

Fixes libarchive#1566
mmatuska added a commit to mmatuska/libarchive that referenced this issue Aug 27, 2021
@mmatuska
Fix following symlinks when processing the fixup list
f452bdc 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing O_DIRECTORY to open() (if supported)
and if it fails to check directory via lstat().

Fixes libarchive#1566
mmatuska added a commit to mmatuska/libarchive that referenced this issue Aug 27, 2021
@mmatuska
Fix following symlinks when processing the fixup list
55695a0 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing O_DIRECTORY to open() (if supported)
and if it fails to check directory via lstat().

Fixes libarchive#1566
mmatuska added a commit to mmatuska/libarchive that referenced this issue Aug 27, 2021
@mmatuska
Fix following symlinks when processing the fixup list
8a1bd5c 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing O_DIRECTORY to open() (if supported)
and if it fails to check directory via lstat().

Fixes libarchive#1566
@ret2libc
Copy link

ret2libc commented Dec 1, 2021

Can Red Hat assign a CVE for this security issue? Or was it already requested to MITRE?

dongsupark added a commit to flatcar-archive/portage-stable that referenced this issue Dec 9, 2021
@dongsupark
app-arch/libarchive: update to 3.5.2
f2b8a86 
Update app-arch/libarchive to 3.5.2, to mainly address security issues
like libarchive/libarchive#1565,
libarchive/libarchive#1566.
@dongsupark dongsupark mentioned this issue Dec 9, 2021
Merged
1 task
@ret2libc
Copy link

ping @mmatuska

@mmatuska
Copy link
Member Author

Hi, a CVE was not requested for this issue, feel free to assign one if you want.

@carnil
Copy link

carnil commented Dec 17, 2021

CVE-2021-31566 appears to have been assigned for this issue.

antekone pushed a commit to antekone/libarchive that referenced this issue Feb 6, 2022
@mmatuska @antekone
Do not follow symlinks when processing the fixup list
cc2cb19 
Use lchmod() instead of chmod() and tell the remaining functions that the
real file to be modified is a symbolic link.

Fixes libarchive#1566
antekone pushed a commit to antekone/libarchive that referenced this issue Feb 6, 2022
@mmatuska @antekone
Fix following symlinks when processing the fixup list
40e079e 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing O_DIRECTORY to open() (if supported)
and if it fails to check directory via lstat().

Fixes libarchive#1566
mmatuska added a commit to mmatuska/libarchive that referenced this issue Feb 7, 2022
@mmatuska
Fix following symlinks when processing the fixup list
4f8ad2f 
The previous fix in b41daec was incomplete. Fixup entries are
given the original path without calling cleanup_pathname().
To make sure we don't follow a symlink, we must strip trailing
slashes from the path.

The fixup entries are always directories. Make sure we try to modify
only directories by providing O_DIRECTORY to open() (if supported)
and if it fails to check directory via lstat().

Fixes libarchive#1566
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ret2libc @carnil @mmatuska