Bug 14047 - dump new security issue CVE-2014-4607
Summary: dump new security issue CVE-2014-4607
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/604237/
Whiteboard: MGA3TOO has_procedure advisory mga3-3...
Keywords: validated_update
Depends on:
Blocks: 13943
  Show dependency treegraph
 
Reported: 2014-09-03 14:55 CEST by David Walser
Modified: 2014-09-15 12:37 CEST (History)
2 users (show)

See Also:
Source RPM: dump-0.4b44-3.mga4.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2014-09-03 14:55:27 CEST
dump bundles minilzo, which is affected by the CVE-2014-4607 issue from the LZO library.

Patched packages uploaded for Mageia 3, Mageia 4, and Cauldron by Oden.

Oden has asked us to test this one more extensively, i.e. to actually test its use of lzo (because the patch was more involved in this case).  You can use the dump command with the -y option to make a compressed backup to a file, and then use the restore command to extract it.  It would look something like this:

dump -y -f backup.dump files-and-dirs-to-backup
restore -C -f backup.dump

That restore command won't actually extract, it'll just compare the backed up files to the ones on disk and tell you if any don't match (if I understand the man pages correctly).

Advisory:
========================

Updated dump packages fix security vulnerability:

An integer overflow in liblzo before 2.07 allows attackers to cause a denial
of service or possibly code execution in applications using performing LZO
decompression on a compressed payload from the attacker (CVE-2014-4607).

The dump package is built with a bundled copy of minilzo, which is a part of
liblzo containing the vulnerable code.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4607
http://advisories.mageia.org/MGASA-2014-0290.html
========================

Updated packages in core/updates_testing:
========================
dump-0.4b44-2.1.mga3
rmt-0.4b44-2.1.mga3
dump-0.4b44-3.1.mga4
rmt-0.4b44-3.1.mga4

from SRPMS:
dump-0.4b44-2.1.mga3.src.rpm
dump-0.4b44-3.1.mga4.src.rpm

Reproducible: 

Steps to Reproduce:
David Walser 2014-09-03 14:55:53 CEST

Blocks: (none) => 13943
Whiteboard: (none) => MGA3TOO

David Walser 2014-09-03 14:57:17 CEST

Whiteboard: MGA3TOO => MGA3TOO has_procedure

Comment 1 William Kenney 2014-09-03 18:55:53 CEST
In VirtualBox, M3, KDE, 32-bit

Package(s) under test:
dump rmt

default install of dump & rmt

[root@localhost wilcal]# urpmi dump
Package dump-0.4b44-2.mga3.i586 is already installed
[root@localhost wilcal]# urpmi rmt
Package rmt-0.4b44-2.mga3.i586 is already installed

(In reply to David Walser from comment #0)

> Oden has asked us to test this one more extensively, i.e. to actually test
> its use of lzo (because the patch was more involved in this case).  You can
> use the dump command with the -y option to make a compressed backup to a
> file, and then use the restore command to extract it.  It would look
> something like this:
> 
> dump -y -f backup.dump files-and-dirs-to-backup
> restore -C -f backup.dump

"It would look something like this:" ???

I have a directory:

/home/wilcal/mageia_3_install

in which there are 27 files

I have created /home/wilcal/dump

Please have Oden share with us the exact dump command he wants
using this directory as a source. I've tried a number of dump
commands that don't work. I'm not familiar with dump. Lets also
get a "restore" command that takes the dump file contained in
/home/wilcal/dump and restore that to /home/wilcal/dump_restore

dump -y -f /home/wilcal/dump backup.dump /home/wilcal/mageia_3_install

results in:
[root@localhost wilcal]# dump -y -f /home/wilcal/dump backup.dump /home/wilcal/mageia_3_install
  DUMP: Date of this level 0 dump: Wed Sep  3 09:51:06 2014
  DUMP: Dumping backup.dump (an unlisted file system) to /home/wilcal/dump
  DUMP: Cannot open backup.dump
  DUMP: The ENTIRE dump is aborted.
  
[root@localhost wilcal]# dump -y /home/wilcal/dump backup.dump -f /home/wilcal/mageia_3_install
  DUMP: Date of this level 0 dump: Wed Sep  3 09:53:50 2014
  DUMP: Dumping /dev/sda6 (/home (dir /wilcal/dump)) to /home/wilcal/mageia_3_install
  DUMP: Label: none
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output (lzo)
  DUMP: mapping (Pass I) [regular files]
  DUMP: File cannot be accessed (backup.dump).
  DUMP: The ENTIRE dump is aborted.

I'm sure I've got something wrong in the syntax somewhere.

Thanks

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
Mageia 4 64-bit, Nvidia driver
virtualbox-4.3.10-1.1.mga4.x86_64
virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64

CC: (none) => wilcal.int

Comment 2 David Walser 2014-09-03 19:12:52 CEST
Yes you messed up the command.  Should be:
dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install

Doing a restore to extract is not necessary, a Compare is fine:
restore -C -f /home/wilcal/dump/backup.dump
Comment 3 William Kenney 2014-09-03 21:25:04 CEST
In VirtualBox, M3, KDE, 32-bit

Package(s) under test:
dump rmt

default install of dump & rmt

[root@localhost wilcal]# urpmi dump
Package dump-0.4b44-2.mga3.i586 is already installed
[root@localhost wilcal]# urpmi rmt
Package rmt-0.4b44-2.mga3.i586 is already installed

dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install
backup a local directory to file backup.dump
restore -r -f backup.dump
restores files in backup.dump into /home/wilcal/dump

install dump & rmt from updates_testing

[root@localhost wilcal]# urpmi dump
Package dump-0.4b44-2.1.mga3.i586 is already installed
[root@localhost wilcal]# urpmi rmt
Package rmt-0.4b44-2.1.mga3.i586 is already installed

dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install
backup a local directory to file backup.dump
restore -r -f backup.dump
restores files in backup.dump into /home/wilcal/dump_14047

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)
Mageia 4 64-bit, Nvidia driver
virtualbox-4.3.10-1.1.mga4.x86_64
virtualbox-guest-additions-4.3.10-1.1.mga4.x86_64
Comment 4 David Walser 2014-09-03 21:26:45 CEST
Have you run a Compare (the -C option I said earlier) to ensure that the uncompressed data is the same as the original data?
Comment 5 William Kenney 2014-09-03 21:40:38 CEST
(In reply to David Walser from comment #4)

> Have you run a Compare (the -C option I said earlier) to ensure that the
> uncompressed data is the same as the original data?

restore -C -f backup.dump

Showing 58 compare errors and a bunch of
./wilcal/.mozilla: (inode 130310) not found on tape
errors. And nothing gets restored.
Comment 6 David Walser 2014-09-03 22:00:23 CEST
(In reply to William Kenney from comment #5)
> (In reply to David Walser from comment #4)
> 
> > Have you run a Compare (the -C option I said earlier) to ensure that the
> > uncompressed data is the same as the original data?
> 
> restore -C -f backup.dump
> 
> Showing 58 compare errors and a bunch of

that's not good

> ./wilcal/.mozilla: (inode 130310) not found on tape

Why is it looking for that?  I thought you created the dump file by backing up /home/wilcal/mageia_3_install

> errors. And nothing gets restored.

It's not supposed to restore anything.
Comment 7 William Kenney 2014-09-04 01:02:14 CEST
(In reply to David Walser from comment #6)

> > Showing 58 compare errors and a bunch of
> 
> that's not good......

I'm pretty confident that the dump & restore commands,
even through executed as sysadmin, arn't gonna screw
up my production M4 i586 system so I'll tinker with
them here. And it's on real hardware.

I think we should be able to get this thing down to
two simple command lines. I think the first one works
fine and that's:

dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_4_install

First I create /home/wilcal/dump

Then:

[root@shermanm4 wilcal]# dump -y -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_4_install
  DUMP: Date of this level 0 dump: Wed Sep  3 15:40:59 2014
  DUMP: Dumping /dev/sda6 (/home (dir /wilcal/mageia_4_install)) to /home/wilcal/dump/backup.dump
  DUMP: Label: none
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output (lzo)
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 52204 blocks.
  DUMP: Volume 1 started with block 1 at: Wed Sep  3 15:40:59 2014                                                     
  DUMP: dumping (Pass III) [directories]                                                                               
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing /home/wilcal/dump/backup.dump
  DUMP: Volume 1 completed at: Wed Sep  3 15:41:01 2014
  DUMP: Volume 1 took 0:00:02
  DUMP: Volume 1 transfer rate: 18477 kB/s
  DUMP: Volume 1 52190kB uncompressed, 36955kB compressed, 1.413:1
  DUMP: 52190 blocks (50.97MB) on 1 volume(s)
  DUMP: finished in 2 seconds, throughput 26095 kBytes/sec
  DUMP: Date of this level 0 dump: Wed Sep  3 15:40:59 2014
  DUMP: Date this dump completed:  Wed Sep  3 15:41:01 2014
  DUMP: Average transfer rate: 18477 kB/s
  DUMP: Wrote 52190kB uncompressed, 36955kB compressed, 1.413:1
  DUMP: DUMP IS DONE

That creates /home/wilcal/dump/backup.dump

No errors are reported so I assume everything went just fine.
I don't have to be in /home/wilcal/dump to make it happen.
So I think we can agree that this is a success. Now we should
be able to extract the archived files into the same directory
using restore. In /home/wilcal/dump I do this:

[root@shermanm4 dump]# restore -r -f backup.dump                                                                       
Dump tape is compressed.                                                                                               
./lost+found: (inode 11) not found on tape                                                                             
./live: (inode 12) not found on tape                                                                                   
./wilcal/.MgaOnline: (inode 49020930) not found on tape                                                                
./wilcal/.bash_completion: (inode 49020932) not found on tape                                                          
./wilcal/.bash_logout: (inode 49020933) not found on tape                                                              
./wilcal/.bash_profile: (inode 49020934) not found on tape                                                             
./wilcal/.bashrc: (inode 49020935) not found on tape                                                                   
./wilcal/.desktop: (inode 49020931) not found on tape
.......
.......
.......
./wilcal/advisories: (inode 49021151) not found on tape
./wilcal/.Skype: (inode 49021120) not found on tape
./wilcal/.cddb: (inode 49152696) not found on tape
./wilcal/dump: (inode 49022487) not found on tape

Not quite sure what all that is about but indeed the backed up
directory was restored as: /home/wilcal/dump/wilcal/mageia_4_install
So now I have the original directory and the restored directory.
Lets see if the restore -C works one against the other.

restore -C -f /home/wilcal/dump/backup.dump /home/wilcal/dump/wilcal/mageia_4_install
just gets me lots of the same thing as in "not found on tape" above.

Tomorrow more tinkering.
Comment 8 claire robinson 2014-09-08 15:54:00 CEST
Testing complete mga4 64

Testing this slightly differently.

From the man page and some googling: restore -C, which is to check/compare the dump file with the filesystem, first cd's to the filesystem root. That is normally going to be /home. It then shows 'not found on tape' errors for each file in /home which is not on the tape, or dump file in this case.

Running it interactively instead, as if to perform the restore, it is possible to change directory, add the dumped directory to be restored and list it's contents. Restore actually states that the dump file is compressed, so it is then able to read the compression, which is the crux of this update. I didn't extract the files as it's a potentially hazardous process.

Started in directory 'test' I made directory 'stuff' and copied some random test files into it.

$ cd test
$ ls
stuff/
$ ls stuff/
test2.apc     test.dxf~  testing               testphp-memcache1.php  testphp-pear.php  test.sh~*     testxml.py
testdata.xml  test.fig   testoutput.prn        testphp-memcache2.php  test.py           test.tar      testxsel.sh
test.dxf      test.gif   testphp-mbstring.php  testphp-memcache.php   test.sh           testtest.iso

I used sudo but you could 'su' (without the -) if you prefer.

$ sudo dump -y -f stuff.dump stuff
  DUMP: Date of this level 0 dump: Mon Sep  8 14:37:13 2014
  DUMP: Dumping /dev/mapper/vg--mga-home (/home (dir /claire/test/stuff)) to stuff.dump
  DUMP: Label: none
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output (lzo)
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 7170 blocks.
  DUMP: Volume 1 started with block 1 at: Mon Sep  8 14:37:13 2014
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing stuff.dump
  DUMP: Volume 1 completed at: Mon Sep  8 14:37:13 2014
  DUMP: 7170 blocks (7.00MB) on 1 volume(s)
  DUMP: finished in less than a second
  DUMP: Date of this level 0 dump: Mon Sep  8 14:37:13 2014
  DUMP: Date this dump completed:  Mon Sep  8 14:37:13 2014
  DUMP: Average transfer rate: 0 kB/s
  DUMP: Wrote 7170kB uncompressed, 2598kB compressed, 2.760:1
  DUMP: DUMP IS DONE

$ ll
total 2604
drwxr-xr-x 2 claire claire   4096 Sep  8 13:52 stuff/
-rw-r--r-- 1 root    root    2660771 Sep  8 14:37 stuff.dump

$ sudo restore -i -f stuff.dump 
Dump tape is compressed.
restore > cd claire/test
restore > ls
./claire/test:
stuff/

restore > add stuff
restore > ls
./claire/test:
*stuff/

restore > ls stuff
./claire/test/stuff:
*test.dxf              *test.tar              *testphp-memcache1.php
*test.dxf~             *test2.apc             *testphp-memcache2.php
*test.fig              *testdata.xml          *testphp-pear.php
*test.gif              *testing               *testtest.iso
*test.py               *testoutput.prn        *testxml.py
*test.sh               *testphp-mbstring.php  *testxsel.sh
*test.sh~              *testphp-memcache.php

restore > quit

This doesn't actually extract anything but does create a directory structure (claire/test/stuff) in the test directory, owned by root. Be careful when deleting it..

$ ll
total 2608
drwx------ 3 root    root       4096 Sep  8 14:43 claire/
drwxr-xr-x 2 claire claire    4096 Sep  8 13:52 stuff/
-rw-r--r-- 1 root    root    2660771 Sep  8 14:37 stuff.dump

$ sudo rm -rf claire
$ sudo rm stuff.dump

Whiteboard: MGA3TOO has_procedure => MGA3TOO has_procedure mga4-64-ok

Comment 9 David Walser 2014-09-08 16:28:26 CEST
Still, does that confirm that it can produce uncompressed data that matches the original data?
Comment 10 claire robinson 2014-09-08 16:37:17 CEST
It shows it can read the lzo compressed dump file AFAICT. I haven't found a way to use -C and restrict it to the dumped directory. It's not really a tar kind of tool, it's more aimed at backing up block devices.

The errors shown in restore -C -f stuff.dump are all 'not found on tape' and relate to the files/directories in /home (on my system where /home is a partition) not having been included in the dump.

Crucially though it doesn't complain that it is unable to read the lzo compressed dump.

I'm not prepared to extract the files to test beyond this due to the block nature and possible root owned filesystem it may leave in it's wake.
Comment 11 William Kenney 2014-09-08 16:44:35 CEST
(In reply to David Walser from comment #9)

> Still, does that confirm that it can produce uncompressed data that matches
> the original data?

After spending too many decades in the backup/restore
industry. Best way to test a backup system is to execute
the backup to some media, whatever that is. Restore it
to something else, whatever that is. Then compare the
original media that was backed up to what was restored.
You then count the errors. 1 error in 10-13th was common
for tape. At the level we should be testing dump/restore
we should see any errors.
Comment 12 William Kenney 2014-09-08 16:48:39 CEST
(In reply to William Kenney from comment #11)

> for tape. At the level we should be testing dump/restore
> we should see any errors.

s/b 

> for tape. At the level we should be testing dump/restore
> we should not see any errors.
Comment 13 claire robinson 2014-09-08 17:01:18 CEST
With -v for verbose..

$ sudo restore -C -v -f stuff.dump

<.. snip lots of 'not found on tape' errors..>

Begin compare restore
Verify tape and initialize maps
Input is from a local file/pipe
Input block size is 10
Dump   date: Mon Sep  8 15:45:33 2014
Dumped from: the epoch
Level 0 dump of /home (dir /claire/test/stuff) on localhost:/dev/mapper/vg--mga-home
Label: none
filesys = /home
Initialize symbol table.
Extract directories from tape
comparing ./claire/test/stuff/test2.apc (size: 9189, mode: 0100644)
comparing ./claire/test/stuff/testdata.xml (size: 694, mode: 0100644)
comparing ./claire/test/stuff/test.dxf (size: 12306, mode: 0100644)
comparing ./claire/test/stuff/test.dxf~ (size: 12066, mode: 0100644)
comparing ./claire/test/stuff/test.fig (size: 327, mode: 0100644)
comparing ./claire/test/stuff/test.gif (size: 2831, mode: 0100644)
comparing ./claire/test/stuff/testing (size: 0, mode: 0100644)
comparing ./claire/test/stuff/testoutput.prn (size: 260971, mode: 0100644)
comparing ./claire/test/stuff/testphp-mbstring.php (size: 556, mode: 0100644)
comparing ./claire/test/stuff/testphp-memcache1.php (size: 841, mode: 0100644)
comparing ./claire/test/stuff/testphp-memcache2.php (size: 267, mode: 0100644)
comparing ./claire/test/stuff/testphp-memcache.php (size: 1015, mode: 0100644)
comparing ./claire/test/stuff/testphp-pear.php (size: 321, mode: 0100644)
comparing ./claire/test/stuff/test.py (size: 106, mode: 0100644)
comparing ./claire/test/stuff/test.sh (size: 307, mode: 0100644)
comparing ./claire/test/stuff/test.sh~ (size: 308, mode: 0100744)
comparing ./claire/test/stuff/test.tar (size: 0, mode: 0100644)
comparing ./claire/test/stuff/testtest.iso (size: 3819520, mode: 0100600)
comparing ./claire/test/stuff/testxml.py (size: 267, mode: 0100644)
comparing ./claire/test/stuff/testxsel.sh (size: 107, mode: 0100644)
Compare directories modes, owner, attributes.
comparing directory .
comparing directory ./claire
comparing directory ./claire/test
comparing directory ./claire/test/stuff
Check the symbol table.
Some files were modified!  342 compare errors
Comment 14 claire robinson 2014-09-08 19:24:33 CEST
Testing complete mga3 32

As before..

$ sudo dump -y -v -f stuff.dump stuff

The -v here doesn't really add anything. It already shows it compresses the data.

$ sudo restore -C -v -f stuff.dump

Adding the -v for verbose shows the compares at the end of the 'not found on tape' errors.

Whiteboard: MGA3TOO has_procedure mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-64-ok

Comment 15 claire robinson 2014-09-09 18:35:15 CEST
Testing complete mga4 32

As comment 14

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok

Comment 16 William Kenney 2014-09-09 19:27:44 CEST
In VirtualBox, M3, KDE, 64-bit

Package(s) under test:
dump

default install of dump

[root@localhost dump]# urpmi dump
Package dump-0.4b44-2.mga3.x86_64 is already installed

dump -y -v -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install
creates the backup.dump file
restore -r -f backup.dump
restores backup.dump to /home/wilcal/dump/
restore -C -v -f backup.dump
compares backup.dump to /home/wilcal/mageia_3_install

install dump rmt from updates_testing

[root@localhost dump]# urpmi dump
Package dump-0.4b44-2.1.mga3.x86_64 is already installed

dump -y -v -f /home/wilcal/dump/backup.dump /home/wilcal/mageia_3_install
creates the backup.dump file
restore -r -f backup.dump
restores backup.dump to /home/wilcal/dump/
restore -C -v -f backup.dump
compares backup.dump to /home/wilcal/mageia_3_install
William Kenney 2014-09-09 19:28:09 CEST

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

Comment 17 William Kenney 2014-09-09 19:30:29 CEST
For me this update works fine.
Testing complete for mga3 32-bit & 64-bit
Testing complete for mga4 32-bit & 64-bit
I'm not entirely happy with the way we are testing
this but from what I can see the update is successful.
If I don't hear from anyone else in 24-hours I'll validate it.
Comment 18 claire robinson 2014-09-10 15:54:26 CEST
Advisory uploaded.

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

Comment 19 William Kenney 2014-09-10 17:25:13 CEST
Validating the update.
Could someone from the sysadmin team push this to updates.
Thanks

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 20 Mageia Robot 2014-09-15 12:37:22 CEST
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0378.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.