Bug 1311616 - CVE-2016-3077 The API crashes when parsing unexpected version numbers
Summary: CVE-2016-3077 The API crashes when parsing unexpected version numbers
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 3.6.3.3
Hardware: Unspecified
OS: Unspecified
unspecified
high vote
Target Milestone: ovirt-3.6.4
: 3.6.4
Assignee: Juan Hernández
QA Contact: Karolína Hajná
URL:
Whiteboard:
Depends On:
Blocks: 1317258 CVE-2016-3077
TreeView+ depends on / blocked
 
Reported: 2016-02-24 15:30 UTC by Juan Hernández
Modified: 2016-11-08 16:28 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-05 13:54:17 UTC
oVirt Team: Infra
juan.hernandez: ovirt-3.6.z?
juan.hernandez: planning_ack?
juan.hernandez: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 54002 0 'None' 'MERGED' 'restapi: Don''t fail with unexpected version numbers' 2019-12-03 07:54:39 UTC
oVirt gerrit 54316 0 'None' 'MERGED' 'restapi: Don''t fail with unexpected version numbers' 2019-12-03 07:54:39 UTC
oVirt gerrit 54423 0 'None' 'MERGED' 'restapi: Don''t fail with unexpected version numbers' 2019-12-03 07:54:39 UTC

Description Juan Hernández 2016-02-24 15:30:29 UTC
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 12:36:25 UTC
Juan - should we target to 3.6.5?

Comment 2 Juan Hernández 2016-03-03 11:23:46 UTC
This same also happens when parsing the version product number, so I'm raising the severity.

Comment 3 Sven Kieske 2016-03-03 12:25:12 UTC
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 12:36:27 UTC
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 13:00:41 UTC
Verified on 3.6.4-0.1.el6

Comment 6 Adam Mariš 2016-03-24 09:19:45 UTC
(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 09:27:54 UTC
(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.