Bug 1311616

Summary: CVE-2016-3077 The API crashes when parsing unexpected version numbers
Product: [oVirt] ovirt-engine Reporter: Juan Hernández <juan.hernandez>
Component: RestAPIAssignee: Juan Hernández <juan.hernandez>
Status: CLOSED CURRENTRELEASE QA Contact: Karolína Hajná <khajna>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.6.3.3CC: bugs, juan.hernandez, oourfali, pstehlik, sbonazzo, s.kieske
Target Milestone: ovirt-3.6.4Flags: juan.hernandez: ovirt-3.6.z?
juan.hernandez: planning_ack?
juan.hernandez: devel_ack+
pstehlik: testing_ack+
Target Release: 3.6.4   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-05 13:54:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1317258, 1321972    

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.