Bug 1691640 (CVE-2019-0160)

Summary: CVE-2019-0160 edk2: Buffer overflows in PartitionDxe and UdfDxe with long file names and invalid UDF media
Product: [Other] Security Response Reporter: Riccardo Schirone <rschiron>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: berrange, choma, crobinso, kraxel, lersek, nsl, pbonzini, philmd, virt-maint, virt-maint
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Buffer overflows were discovered in UDF-related codes under MdeModulePkg\Universal\Disk\PartitionDxe\Udf.c and MdeModulePkg\Universal\Disk\UdfDxe, which could be triggered with long file names or invalid formatted UDF media.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 13:22:19 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1691646, 1691645, 1691647, 1691648    
Bug Blocks: 1683431    
Attachments:
Description Flags
Read text file in the UefiShell.iso
none
type autorun.inf none

Description Riccardo Schirone 2019-03-22 07:15:09 UTC
Buffer overflows on the stack/heap are found in UDF-related codes under MdeModulePkg\Universal\Disk\PartitionDxe\Udf.c and MdeModulePkg\Universal\Disk\UdfDxe. The issue may be triggered with long file name (> 128 characters) or path name (> 256 characters) or with invalid formatted UDF media.

Comment 1 Riccardo Schirone 2019-03-22 07:18:00 UTC
See bug 1683404, bug 1683410, bug 1683413, bug 1683421, bug 1683425.

Comment 3 Riccardo Schirone 2019-03-22 07:22:18 UTC
Created edk2 tracking bugs for this issue:

Affects: epel-all [bug 1691646]
Affects: fedora-all [bug 1691645]

Comment 5 Laszlo Ersek 2019-03-22 18:05:38 UTC
Testing method for virt-QE:

Sanity checking is sufficient.

(1)   Install a new RHEL or Fedora guest from a Live or installer ISO.

(2)   Boot the installed system

(3.1) Partition a physical USB stick with MBR partition table format,
      and create a single FAT32 partition on it. Copy a small text file
      to the FAT32 filesystem. (You can use normal RHEL tools for this,
      on the host.)

(3.2) Assign the USB stick with virtio-scsi "LUN passthrough" to the
      guest.

      <disk type='block' device='lun'>
      https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/storage_vols#sect-Storage_Volumes-Adding_storage_devices_to_guests

      Note that you should assign the device node from the host system
      that represents the entire USB stick, i.e. not just a partition of
      it.

(3.3) Boot UefiShell.iso in the guest, and check with the TYPE shell
      command whether the text file can be read. (For best results you
      might have to use CRLF in the text file.)

(4.1) Add two ISO images to a domain configuration, UefiShell.iso and
      some Windows installer ISO. In this example I use
      "en_windows_server_2012_r2_x64_dvd_2707946.iso", but other Windows
      media should work too.

(4.2) Add only UefiShell.iso to the boot order.

(4.3) In the UEFI Shell, run the MAP command. Locate the "FSx:" alias
      whose UEFI device path ends with a
      VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A) device path node.
      For example:

> FS2: Alias(s):F0a1:;BLK8:
>     PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)/VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A)

(4.4) Change to the filesystem in question, and list a file with the
      TYPE command that is likely a text file. For example:

> Shell> fs2:
>
> FS2:\> dir
> Directory of: FS2:\
> 08/22/2013  10:07       r         128  autorun.inf
> 08/22/2013  10:07 <DIR> r         564  boot
> 08/22/2013  10:07       r     427,680  bootmgr
> 08/22/2013  10:07       r   1,612,128  bootmgr.efi
> 08/22/2013  10:07 <DIR> r         148  efi
> 08/22/2013  10:07       r      77,424  setup.exe
> 08/22/2013  10:07 <DIR> r      13,128  sources
> 08/22/2013  10:07 <DIR> r         252  support
>           4 File(s)   2,117,360 bytes
>           4 Dir(s)
>
> FS2:\> type autorun.inf
> [AutoRun.Amd64]
> open=setup.exe
> icon=setup.exe,0
>
> [AutoRun]
> open=sources\SetupError.exe x64
> icon=sources\SetupError.exe,0
>
> FS2:\>

Step (1) will regression-test ISO9960/ElTorito, when booting the ISO
image.

Step (2) will regression-test GPT.

Step (3) will regression-test MBR.

Step (4) will regression-test UDF.

Thanks!

Comment 6 Laszlo Ersek 2019-03-22 19:53:39 UTC
(In reply to Laszlo Ersek from comment #5)
> Testing method for virt-QE:

> (3.1) Partition a physical USB stick with MBR partition table format,
>       and create a single FAT32 partition on it. Copy a small text file
>       to the FAT32 filesystem. (You can use normal RHEL tools for this,
>       on the host.)
> 
> (3.2) Assign the USB stick with virtio-scsi "LUN passthrough" to the
>       guest.
> 
>       <disk type='block' device='lun'>
>      
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
> html/virtualization_deployment_and_administration_guide/storage_vols#sect-
> Storage_Volumes-Adding_storage_devices_to_guests
> 
>       Note that you should assign the device node from the host system
>       that represents the entire USB stick, i.e. not just a partition of
>       it.

Don't forget to unmount any filesystems located on the USB stick from the host, between steps (3.1) and (3.2).

Comment 7 Laszlo Ersek 2019-03-22 20:18:29 UTC
(In reply to Laszlo Ersek from comment #5)

> (3.3) Boot UefiShell.iso in the guest, and check with the TYPE shell
>       command whether the text file can be read. (For best results you
>       might have to use CRLF in the text file.)

> (4.3) In the UEFI Shell, run the MAP command. Locate the "FSx:" alias
>       whose UEFI device path ends with a
>       VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A) device path node.
>       For example:
> 
> > FS2: Alias(s):F0a1:;BLK8:
> >     PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)/VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A)


A hint for the above steps -- because we launch the UEFI shell from
UefiShell.iso as a "boot loader", it will not see and report all
devices/drivers connected, in the MAP command. This is the right
behavior, but for this test case we do want to see everything.
Therefore, when the UEFI shell is reached, first run:

  connect -r
  map -r

Comment 8 Michael 2019-05-15 09:02:48 UTC
(In reply to Laszlo Ersek from comment #5)

Hi Laszlo:

I am verifying Bug 1691647. According Bug 1691647#c3. I update the result in here. 

> Testing method for virt-QE:
> 
> Sanity checking is sufficient.
> 
> (1)   Install a new RHEL or Fedora guest from a Live or installer ISO.

Success. 

> 
> (2)   Boot the installed system

Success.

> 
> (3.1) Partition a physical USB stick with MBR partition table format,
>       and create a single FAT32 partition on it. Copy a small text file
>       to the FAT32 filesystem. (You can use normal RHEL tools for this,
>       on the host.)
> 

In the host:
[1] #lsblk
    NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    sda             8:0    0 465.8G  0 disk 
    ├─sda1          8:1    0   200M  0 part /boot/efi
    ├─sda2          8:2    0     1G  0 part /boot
    └─sda3          8:3    0 464.6G  0 part 
      ├─rhel-root 253:0    0    50G  0 lvm  /
      ├─rhel-swap 253:1    0   7.8G  0 lvm  [SWAP]
      └─rhel-home 253:2    0 406.8G  0 lvm  /home
    sdb             8:16   1  28.9G  0 disk    <== This is the physical USB stick. 
    └─sdb1          8:17   1  28.9G  0 part 
    sr0            11:0    1  1024M  0 rom  


[2] #fdisk /dev/sdb
    Command (m for help): p

    Disk /dev/sdb: 31.0 GB, 31004295168 bytes, 60555264 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    ***Disk label type: dos***
    Disk identifier: 0xc4ad5995

    Device Boot         Start         End      Blocks   Id  System
    /dev/sdb1            2048    60555263    30276608   83  Linux

[3] #df -T
Filesystem                       Type      1K-blocks      Used Available Use% Mounted on
/dev/sdb1                        vfat       30261808        48  30261760   1% /mnt/sdb1


> (3.2) Assign the USB stick with virtio-scsi "LUN passthrough" to the
>       guest.
> 
>       <disk type='block' device='lun'>
>      
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/
> html/virtualization_deployment_and_administration_guide/storage_vols#sect-
> Storage_Volumes-Adding_storage_devices_to_guests
> 
>       Note that you should assign the device node from the host system
>       that represents the entire USB stick, i.e. not just a partition of
>       it.

Boot guest and passthrough USB stick. 

/usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4G -smp 4 -nodefaults \
-global driver=cfi.pflash01,property=secure,value=on \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/tmp/new-edk2-version/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=off \
-device pcie-root-port,id=pcie.0-root-port-2,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-4,slot=4,chassis=4,addr=0x4,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-5,slot=5,chassis=5,addr=0x5,bus=pcie.0 \
-device virtio-scsi-pci,id=scsi0,bus=pcie.0-root-port-2,addr=0x0 \
-object secret,id=sec0,data=redhat \
-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/mnt/test/personal/choma/guest-nfs/rhel7.7-host/rhel7.7-ovmf.luks,node-name=protocol-node \
-blockdev node-name=format-node,driver=luks,file=protocol-node,key-secret=sec0 \
-device scsi-hd,bus=scsi0.0,drive=format-node \

-device virtio-scsi-pci,id=scsi1,bus=pcie.0-root-port-4,addr=0x0 \
-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/dev/sdb,node-name=protocol-node-1 \
-blockdev node-name=format-node-1,driver=raw,file=protocol-node-1 \
-device scsi-hd,bus=scsi0.0,drive=format-node-1,bootindex=3 \

-drive file=/usr/share/OVMF/UefiShell.iso,if=none,cache=none,snapshot=off,aio=native,media=cdrom,id=cdrom1 -device ahci,id=ahci0 -device ide-cd,drive=cdrom1,id=ide-cd1,bootindex=2  \
-device virtio-net-pci,mac=24:be:05:15:d3:90,id=netdev1,vectors=4,netdev=net1,bus=pcie.0-root-port-3 -netdev tap,id=net1,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-cdrom en_windows_10_business_edition_version_1809_updated_sept_2018_x64_dvd_f0b7dc68.iso \
-vnc :1 -monitor stdio -vga qxl -boot menu=on,splash-time=5000 \


> 
> (3.3) Boot UefiShell.iso in the guest, and check with the TYPE shell
>       command whether the text file can be read. (For best results you
>       might have to use CRLF in the text file.)

please see "Read text file in the UefiShell.iso"

> 
> (4.1) Add two ISO images to a domain configuration, UefiShell.iso and
>       some Windows installer ISO. In this example I use
>       "en_windows_server_2012_r2_x64_dvd_2707946.iso", but other Windows
>       media should work too.
> 
> (4.2) Add only UefiShell.iso to the boot order.
> 
> (4.3) In the UEFI Shell, run the MAP command. Locate the "FSx:" alias
>       whose UEFI device path ends with a
>       VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A) device path node.
>       For example:
> 
> > FS2: Alias(s):F0a1:;BLK8:
> >     PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x0)/Scsi(0x0,0x1)/VenMedia(C5BD4D42-1A76-4996-8956-73CDA326CD0A)
> 
> (4.4) Change to the filesystem in question, and list a file with the
>       TYPE command that is likely a text file. For example:
> 
> > Shell> fs2:
> >
> > FS2:\> dir
> > Directory of: FS2:\
> > 08/22/2013  10:07       r         128  autorun.inf
> > 08/22/2013  10:07 <DIR> r         564  boot
> > 08/22/2013  10:07       r     427,680  bootmgr
> > 08/22/2013  10:07       r   1,612,128  bootmgr.efi
> > 08/22/2013  10:07 <DIR> r         148  efi
> > 08/22/2013  10:07       r      77,424  setup.exe
> > 08/22/2013  10:07 <DIR> r      13,128  sources
> > 08/22/2013  10:07 <DIR> r         252  support
> >           4 File(s)   2,117,360 bytes
> >           4 Dir(s)
> >
> > FS2:\> type autorun.inf
> > [AutoRun.Amd64]
> > open=setup.exe
> > icon=setup.exe,0
> >
> > [AutoRun]
> > open=sources\SetupError.exe x64
> > icon=sources\SetupError.exe,0
> >
> > FS2:\>

please see "type autorun.inf" in the attachment. 


The result looks good. Please have a look. According the testing in above, mark Bug 1691647 verified. 


Thanks.

Comment 9 Michael 2019-05-15 09:04:30 UTC
Created attachment 1568899 [details]
Read text file in the UefiShell.iso

Comment 10 Michael 2019-05-15 09:05:18 UTC
Created attachment 1568901 [details]
type autorun.inf

Comment 11 Laszlo Ersek 2019-05-15 11:20:35 UTC
Hi Michael,

the results look OK, but the QEMU command line doesn't match precisely what I asked for. In comment 5 I wrote,

> (3.2) Assign the USB stick with virtio-scsi "LUN passthrough" to the guest.

On the QEMU command line, that translates to "scsi-block".

However your command line in comment 8 uses "scsi-hd" device(s).

Can you please re-run the test with "scsi-block"? Thanks.

Comment 12 Michael 2019-05-16 02:11:35 UTC
(In reply to Laszlo Ersek from comment #11)
> Hi Michael,
> 
> the results look OK, but the QEMU command line doesn't match precisely what
> I asked for. In comment 5 I wrote,
> 
> > (3.2) Assign the USB stick with virtio-scsi "LUN passthrough" to the guest.
> 
> On the QEMU command line, that translates to "scsi-block".
> 
> However your command line in comment 8 uses "scsi-hd" device(s).
> 
> Can you please re-run the test with "scsi-block"? Thanks.


Hi Laszlo:

Thank you for your information. I have changed the qemu command as follow. Then I repeated the test. I got the exactly same result. 

/usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4G -smp 4 -nodefaults \
-global driver=cfi.pflash01,property=secure,value=on \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/tmp/new-edk2-version/OVMF_VARS.fd,if=pflash,format=raw,unit=1,readonly=off \
-device pcie-root-port,id=pcie.0-root-port-2,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-4,slot=4,chassis=4,addr=0x4,bus=pcie.0 \
-device pcie-root-port,id=pcie.0-root-port-5,slot=5,chassis=5,addr=0x5,bus=pcie.0 \
-device virtio-scsi-pci,id=scsi0,bus=pcie.0-root-port-2,addr=0x0 \
-object secret,id=sec0,data=redhat \
-blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=/mnt/test/personal/choma/guest-nfs/rhel7.7-host/rhel7.7-ovmf.luks,node-name=protocol-node \
-blockdev node-name=format-node,driver=luks,file=protocol-node,key-secret=sec0 \
-device scsi-hd,bus=scsi0.0,drive=format-node \

-device virtio-scsi-pci,id=scsi1,bus=pcie.0-root-port-4,addr=0x0 \
-blockdev driver=host_device,cache.direct=off,cache.no-flush=on,filename=/dev/sdb,node-name=protocol-node-1 \
-blockdev node-name=format-node-1,driver=raw,file=protocol-node-1 \
-device scsi-block,bus=scsi1.0,drive=format-node-1,id=protocol-node-1,bootindex=3 \

-drive file=/usr/share/OVMF/UefiShell.iso,if=none,cache=none,snapshot=off,aio=native,media=cdrom,id=cdrom1 -device ahci,id=ahci0 -device ide-cd,drive=cdrom1,id=ide-cd1,bootindex=2  \
-cdrom en_windows_10_business_edition_version_1809_updated_sept_2018_x64_dvd_f0b7dc68.iso \
-device virtio-net-pci,mac=24:be:05:15:d3:90,id=netdev1,vectors=4,netdev=net1,bus=pcie.0-root-port-3 -netdev tap,id=net1,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
-vnc :1 -monitor stdio -vga qxl -boot menu=on,splash-time=5000 \



If you have any other requirement, just free for let me know. Thanks.

Comment 13 Laszlo Ersek 2019-05-16 12:06:35 UTC
No, nothing else needed. Thank you for retesting.

Comment 14 errata-xmlrpc 2019-08-06 12:18:32 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2019:2125 https://access.redhat.com/errata/RHSA-2019:2125

Comment 15 Product Security DevOps Team 2019-08-06 13:22:19 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2019-0160

Comment 16 errata-xmlrpc 2019-11-05 20:38:21 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2019:3338 https://access.redhat.com/errata/RHSA-2019:3338