Rubyzip gem overwrites write-protected root-owned file

Ruby
1

I’m playing with the rubyzip gem, and found, with this little script:

require ‘rubygems’
require ‘zip/zip’
Zip::ZipFile.open(‘test.zip’, Zip::ZipFile::CREATE) do |zipfile|
zipfile.add(‘rgb.txt’,’/etc/X11/rgb.txt’)
end

that ‘test.zip’ is written without any warning, even if it exists, is
root-owned and write-protected. Is that a bug?

2

Am 24.07.2012 14:44, schrieb Wybo D.:

I’m playing with the rubyzip gem, and found, with this little script:

require ‘rubygems’
require ‘zip/zip’
Zip::ZipFile.open(‘test.zip’, Zip::ZipFile::CREATE) do |zipfile|
zipfile.add(‘rgb.txt’,‘/etc/X11/rgb.txt’)
end

that ‘test.zip’ is written without any warning, even if it exists, is
root-owned and write-protected. Is that a bug?

If you can overwrite a root-owned file not writable by neither a group
you’re in nor for others (i.e. something like rw------- root:root), then
you have a serious security problem (which has nothing to do with Ruby).
Check your system settings (and you’re sure you don’t run this as
root?).

Vale,
Marvin

–
Blog: http://pegasus-alpha.eu/blog

ASCII-Ribbon-Kampagne () | ASCII Ribbon Campaign ()

3

On Thu, Jul 26, 2012 at 07:21:19PM +0900, Wybo D. wrote:

that ‘test.zip’ is written without any warning, even if it exists, is
$ zip test.zip /etc/passwd
zip I/O error: Permission denied
zip error: Could not create output file (test.zip)

So what I think happens is that Rubyzip, instead of adding a file to the
zip, as requested, creates a new zip, deletes the old one (which is
allowed in a directory which I own) and the renames the new zip to the
old filename, thus effectively removing the old zip’s ownership and
permissions.
I think that is not how it should work…

There is something seriously wrong with your system if a program run
as
a nonprivileged user is able to overwrite files owned by root for which
root is the only user that has write permissions. Unless the Ruby
program in question, or your Ruby interpreter itself, has the suid bit
set, it seems the problem is with the system somehow, because this is a
clear violation of privilege separation. There is no way a mere bug in
a
program run as a nonprivileged user should allow it to violate system
privilege separation.

4

On 2012-07-24 16:44, Quintus wrote:

root-owned and write-protected. Is that a bug?

If you can overwrite a root-owned file not writable by neither a group
you’re in nor for others (i.e. something like rw------- root:root), then
you have a serious security problem (which has nothing to do with Ruby).
Check your system settings (and you’re sure you don’t run this as root?).

Well, if I try to add a file using the system zip, I am not allowed to
do so:

$ zip test.zip /etc/passwd
zip I/O error: Permission denied
zip error: Could not create output file (test.zip)

So what I think happens is that Rubyzip, instead of adding a file to the
zip, as requested, creates a new zip, deletes the old one (which is
allowed in a directory which I own) and the renames the new zip to the
old filename, thus effectively removing the old zip’s ownership and
permissions.
I think that is not how it should work…

5

On Fri, Jul 27, 2012 at 07:16:16AM +0900, Wybo D. wrote:

I don’t agree.
First, look at Linux file permissions - Windows Bulletin Tutorials,
which says:
Write permission. On a regular file, this means you can modify the file,
aka write new data to the file. In the case of a directory, the write
permission means you can add, remove, and rename files in the directory.
This means that if a file has the write permission bit, you are allowed
to modify the file’s contents, but you’re allowed to rename or delete
the file only if the permissions of the file’s directory allow you to do so.

You’re right, of course. I completely failed to think about directory
permissions. That’s my mistake; sorry about that.

6

On 2012-07-26 22:17, Chad P. wrote:

There is something seriously wrong with your system if a program run as
a nonprivileged user is able to overwrite files owned by root for which
root is the only user that has write permissions. Unless the Ruby
program in question, or your Ruby interpreter itself, has the suid bit
set, it seems the problem is with the system somehow, because this is a
clear violation of privilege separation. There is no way a mere bug in a
program run as a nonprivileged user should allow it to violate system
privilege separation.

I don’t agree.
First, look at http://www.tuxfiles.org/linuxhelp/filepermissions.html,
which says:
Write permission. On a regular file, this means you can modify the file,
aka write new data to the file. In the case of a directory, the write
permission means you can add, remove, and rename files in the directory.
This means that if a file has the write permission bit, you are allowed
to modify the file’s contents, but you’re allowed to rename or delete
the file only if the permissions of the file’s directory allow you to do
so.

Second, see

Third, go to your own home directory, or better: start a linux live cd,
and try the following:

echo test >t
chmod 0 t
sudo chown root.root t
ls -l t
rm -f t

Your root-owned write-protected t will have disappeared without any
warning. Note that, without the -f option for rm, you get a warning:
rm: remove write-protected regular file `t’?
and you need to type y to remove the file.