Bug 1311616 - CVE-2016-3077 The API crashes when parsing unexpected version numbers
CVE-2016-3077 The API crashes when parsing unexpected version numbers
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
3.6.3.3
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-3.6.4
: 3.6.4
Assigned To: Juan Hernández
Karolína Hajná
:
Depends On:
Blocks: 1317258 CVE-2016-3077
  Show dependency treegraph
 
Reported: 2016-02-24 10:30 EST by Juan Hernández
Modified: 2016-11-08 11:28 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-05 09:54:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
juan.hernandez: ovirt‑3.6.z?
juan.hernandez: planning_ack?
juan.hernandez: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 54002 master MERGED restapi: Don't fail with unexpected version numbers 2016-03-03 12:35 EST
oVirt gerrit 54316 ovirt-engine-3.6 MERGED restapi: Don't fail with unexpected version numbers 2016-03-04 02:37 EST
oVirt gerrit 54423 ovirt-engine-3.6.4 MERGED restapi: Don't fail with unexpected version numbers 2016-03-07 09:02 EST

  None (edit)
Description Juan Hernández 2016-02-24 10:30:29 EST
Currently the API expects that the guest kernel version numbers like "4.2.1-5", but some operating systems use more complicated version numbers, for example "2.6.37.6-24-default". This makes the server crash, with an array index out of bounds exception.

The problem is in the "VersionMapper.fromKernelVersionString" method. It needs to be made more tolerant, supporting versions that don't match the expected format.
Comment 1 Oved Ourfali 2016-02-29 07:36:25 EST
Juan - should we target to 3.6.5?
Comment 2 Juan Hernández 2016-03-03 06:23:46 EST
This same also happens when parsing the version product number, so I'm raising the severity.
Comment 3 Sven Kieske 2016-03-03 07:25:12 EST
isn't this a security issue? you can crash through a version number, this can lead to a dos.
Comment 4 Juan Hernández 2016-03-03 07:36:27 EST
Well, the "crash" is just a failure of the operation that retrieves the representation of a virtual machine, or the summary of the API, not a complete crash of the system.

A malicious user with access to a VM could configure it so that it reports a version number that causes that crash. That would mean than when that VM is reported (also when all VMs are reported) the operation would fail. This can be considered as DoS attack, so in that sense you are right that this can be considered a security issue. But not a serious one, in my opinion.

The problem with the product version is less attackable, because users can't change the product version.
Comment 5 Karolína Hajná 2016-03-18 09:00:41 EDT
Verified on 3.6.4-0.1.el6
Comment 6 Adam Mariš 2016-03-24 05:19:45 EDT
(In reply to Juan Hernández from comment #4)
> Well, the "crash" is just a failure of the operation that retrieves the
> representation of a virtual machine, or the summary of the API, not a
> complete crash of the system.
> 
> A malicious user with access to a VM could configure it so that it reports a
> version number that causes that crash. That would mean than when that VM is
> reported (also when all VMs are reported) the operation would fail. This can
> be considered as DoS attack, so in that sense you are right that this can be
> considered a security issue. But not a serious one, in my opinion.
> 
> The problem with the product version is less attackable, because users can't
> change the product version.

Does one faulty VM report make the retrieval operation for all other VMs to fail?
Comment 7 Oved Ourfali 2016-03-24 05:27:54 EDT
(In reply to Adam Mariš from comment #6)
> (In reply to Juan Hernández from comment #4)
> > Well, the "crash" is just a failure of the operation that retrieves the
> > representation of a virtual machine, or the summary of the API, not a
> > complete crash of the system.
> > 
> > A malicious user with access to a VM could configure it so that it reports a
> > version number that causes that crash. That would mean than when that VM is
> > reported (also when all VMs are reported) the operation would fail. This can
> > be considered as DoS attack, so in that sense you are right that this can be
> > considered a security issue. But not a serious one, in my opinion.
> > 
> > The problem with the product version is less attackable, because users can't
> > change the product version.
> 
> Does one faulty VM report make the retrieval operation for all other VMs to
> fail?

Yes.

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