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.

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

CVE-2013-4184: Insecure usage of /tmp/.UUID_STATE and /tmp/.UUID_NODEID #5

Open
diocles opened this Issue Jul 30, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@diocles

diocles commented Jul 30, 2013

This is a repost and update of https://rt.cpan.org/Public/Bug/Display.html?id=69277 - the bug tracker that CPAN points to appears to have changed at some point since 2011.

A symlink attack via Data::UUID is possible.

As user2:

ln -s /home/user1/test-file /tmp/.UUID_STATE

As user1:

perl -MData::UUID -e 'Data::UUID->new'

Then /home/user1/test-file is overwritten.

There are two points in UUID.xs which write to UUID_STATE_NV_STORE - both the DESTROY() and create() functions are affected.

On at least recent Debian kernels, it is necessary to disable symlink protection via "sysctl fs.protected_symlinks=0" to reproduce this issue.

A similar attack is possible via .UUID_NODEID, but only if combined with exploiting the race condition between fopen and fwrite, so this is much more difficult to reproduce.

@diocles

This comment has been minimized.

Show comment
Hide comment
@diocles

diocles Jul 30, 2013

I have requested a CVE id from oss-security, and I will come back and update the report when one is assigned.

diocles commented Jul 30, 2013

I have requested a CVE id from oss-security, and I will come back and update the report when one is assigned.

@rjbs

This comment has been minimized.

Show comment
Hide comment
@rjbs

rjbs Dec 10, 2013

Owner

I really don't do anything on this library but apply patches. It's been without a dedicated maintainer almost since release. A patch for this issue would be appreciated.

Owner

rjbs commented Dec 10, 2013

I really don't do anything on this library but apply patches. It's been without a dedicated maintainer almost since release. A patch for this issue would be appreciated.

@karenetheridge

This comment has been minimized.

Show comment
Hide comment
@karenetheridge

karenetheridge Apr 20, 2018

We should really fix this. A lot of production code uses it.

karenetheridge commented Apr 20, 2018

We should really fix this. A lot of production code uses it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment