Säkerhetsbrister placerade i Linux-kerneln
En forskningsgrupp vid University of Minnesota (UMN) har undersök om det är möjligt att med flit introducera nya säkerhetsbrister i open-source projekt såsom Linux-kerneln. Just denna forskning har väckt en hel del reaktioner om hur etiskt och moraliskt denna typ av forskning är och samtliga patchar till Linux-kerneln från någon med UMN-epost har dragits tillbaka. Dock så genomfördes dessa illasinnade patchar med någon random-gmail.
Men frågeställningen är så klart intressant. Skulle det vara möjligt för en illasinnad aktör att lägga in sårbarheter medvetet i open-source projekt? Ja, givetvis är det möjligt. Men förhoppningsvis så granskas koden av flertalet ögon innan den gör någon skada. Och just detta är både fördelen och nackdelen med open-source projekt, se bara den PHP-bakdörr som försökte läggas in förra månaden.
How much review a subsystem maintainer does ends up coming down to trust. If driver maintainer is submitting consistently good patches, they may be trusted to submit their patches with less review.
Laura Labbott (källa)
Dock gick forskningen inte så bra och de tre sårbarheter som teamet försökte att introducera så gick ingen igenom (källa):
– UAF case 1, Fig. 11 => crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions, https://lore.kernel.org/lkml/20200821031209.21279-1-acostag…. The day after this patch was merged into a driver tree, the author suggested calling dev_err() before pci_disable_device(), which presumably was their attempt at maintainer notification; however, the code as merged doesn’t actually appear to constitute a vulnerability because pci_disable_device() doesn’t appear to free the struct pci_dev.
– UAF case 2, Fig. 9 => tty/vt: fix a memory leak in con_insert_unipair, https://lore.kernel.org/lkml/20200809221453.10235-1-jameslou… This patch was not accepted.
– UAF case 3, Fig. 10 => rapidio: fix get device imbalance on error, https://lore.kernel.org/lkml/20200821034458.22472-1-acostag…. Same author as case 1. This patch was not accepted.
Och denna kommentar är också rätt intressant: