Hide Forgot
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.
Juan - should we target to 3.6.5?
This same also happens when parsing the version product number, so I'm raising the severity.
isn't this a security issue? you can crash through a version number, this can lead to a dos.
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.
Verified on 3.6.4-0.1.el6
(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?
(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.