[BUG] [V1.1.1] Client PXE environment not sanitizing inputs - Database corruption
-
Hi,
We have just encountered the following issue on v1.1.1:
A user PXE booted a new machine and attempted a full registration, inventory and image. The machine was named “LNG6” but then he fumbled the keyboard and accidentally entered the character ‘/’ as the image ID. The PXE environment didn’t check that this was a real image number or even that it was a valid numeric input. It completed the inventory and attempted a reboot.
The reboot failed with the error “[url]http://192.148.4.1/fog/service/ipxe/boot.php[/url] Input/output error ([url]http://ipxe.org/1d0c6139[/url])” From this point on, it was not possible to net boot that machine to get the menu to delete it. After several failed attempts, the user gave up, took a fresh machine and called that LNG6. The FOG server allowed him to do this even though a machine of this name already existed.
The user visited the FOG management website and found two entries for LNG6 in the database.
[COLOR=#1f497d][FONT=Calibri]The LNG server listed the LNG6 in the hosts lists with the correct MAC address, however it could not be edited or deleted (editing produced an empty host edit page and trying to delete it produced a blank web page with just the URL, containing id=0, in the address bar). It was noticed that “ID=0” was in all URLs to do with this machine where the user thought it should have been ID=211 (machines imaged before and after this was ID 210 and 212). User tried a number of things including typing a URL to specify ID=211, however this did not work. Subsequently, it was found to be possible to change the machine name to “BROKEN” by manually entering the MAC address and new name in the edit page.[/FONT][/COLOR] At this point, the other LNG6 became the only one and appears to be fine.
[COLOR=#1f497d][FONT=Calibri]The MySQL database was accessed directly from the server command line and a SELECT query for the machine produced the following, indicating the problem entry really did have an ID of 0:[/FONT][/COLOR]
[QUOTE]mysql> select * from hosts where hostmac=‘8c:c1:21:a4:6e:b6’;
±-------±---------±---------±-------±----------±-------------±--------------------±--------------------±-------------±------------------±----------±-------------±---------±-----------±-----------±-----------------±---------------±-----------±-----------+
| hostID | hostName | hostDesc | hostIP | hostImage | hostBuilding | hostCreateDate | hostLastDeploy | hostCreateBy | hostMAC | hostUseAD | hostADDomain | hostADOU | hostADUser | hostADPass | hostPrinterLevel | hostKernelArgs | hostKernel | hostDevice |
±-------±---------±---------±-------±----------±-------------±--------------------±--------------------±-------------±------------------±----------±-------------±---------±-----------±-----------±-----------------±---------------±-----------±-----------+
| 0 | BROKEN | | | 0 | 0 | 2014-10-25 11:56:36 | 0000-00-00 00:00:00 | FOGREG | 8c:c1:21:a4:6e:b6 | | | | | | | | | |
±-------±---------±---------±-------±----------±-------------±--------------------±--------------------±-------------±------------------±----------±-------------±---------±-----------±-----------±-----------------±---------------±-----------±-----------+
1 row in set (0.00 sec)
[/QUOTE]To make it possible to image the machine, it had to be forcibly deleted from the database:
[QUOTE]mysql> delete from hosts where hostmac=‘8c:c1:21:a4:6e:b6’;[/QUOTE]
Many thanks for looking,
Paul. -
This isn’t a problem with the “sanitizing” of the fields, though I assure you they are sanitized.
I’m going to guess, the system that inserted, but with a hostID of 0 was also set to be imaged?
This was a known issue of 1.1.1, and I believe it was fixed in 1.1.2 but for sure was fixed in 1.2.0.
