Uutta tietoa Windows-työkalun Classic Shell käyttäjille ja kiinnostuneille: Jatkoprojekti on jo nimetty uudelleen ja se on nyt nimeltään Open Shell Menu. Tässä hieman tietoa ja vihje, miksi (tällä hetkellä) sanoisin ”ole varovainen”.
On olemassa ohjelmistoja, jotka pitävät itsensä huomion keskipisteessä uudelleennimeämisen avulla. Luokittelisin Classic Shell -projektin tähän kategoriaan, sillä tämä projekti on nimetty uudelleen.
Joitakin taustatietoja
Classic Shellin kehittäjä Ivo Beltchev lopetti ohjelmiston kehittämisen jokin aika sitten. Hän kuitenkin antoi lähdekoodin yhteisölle jatkuvaa ylläpitoa varten. Olen kirjoittanut siitä saksalaisessa blogissani.
Mutta mikä ei ole niin mukavaa minun makuuni: Tällä hetkellä projekti tuottaa tällä hetkellä vain otsikoita johtuen useista uudelleennimityksistä. Lyhyen aikaa työkalu oli nimeltään Classic Start. Sitten yhteisö päätti nimetä sen heinäkuun 2018 lopussa uudelleen NeoClassic-UI/Menuksi. Ehkä siihen on hyvät syyt, en tiedä, niitä ei ole koskaan mainittu.
Seuraava uusi nimi …
Ja nyt projekti on nimetty uudelleen Open-Shell-Menuksi. Nykyinen asennustiedosto on nyt nimeltään OpenShellSetup_4_4_126.exe, mutta toiminnallisuus ei liene muuttunut. Projekti on saatavilla GitHubissa, mutta kaikki linkit eivät vielä toimi. Nykyinen Nightly Build on saatavilla täältä, jonka voimassaolo päättyy 6 kuukauden kuluttua.
Tämän projektin pimeä puoli: Security
Puolella ’säkillinen riisiä kaatui Kiinassa, jatkakaa, ei mitään nähtävää’, haluaisin huomauttaa, että sinun pitäisi pitää näppisi erossa tästä työkalusta (ainakin siihen asti, kunnes kehittäjät ovat korjanneet muutamia perustavanlaatuisia asioita). Miksi tämä varoitus?
Olen ollut yhteydessä valkohattuhakkeri Stefan Kanthakiin (ks.) jo pidemmän aikaa (Microsoft on värvännyt hänet Top 100 MSRC 2017 -listalle ja myös muille listoille, kuten Top 100 Finders -listalle vuonna 2015). tutkija vuonna 2015 (ks.).
Stefan Kanthak on lähettänyt saksalaisen kommentin, jossa hahmotellaan joitakin kriittisiä asioita. Tässä lyhyt ote:
- Mukavuuden vuoksi kehittäjät toimittavat .exe-asennusohjelman (.msi-tiedoston sijaan). Tämä asennusohjelma on suoritettava järjestelmänvalvojan oikeuksin ohjelmiston asentamiseksi. Asennusohjelma purkaa tarvittavat tiedostot (suojaamattomaan) TEMP-hakemistoon. Ongelma: Jos järjestelmässä on haittaohjelma, joka toimii tällä hetkellä vain rajoitetun käyttäjätilin oikeuksilla, ansa aktivoituu.
- Tämä haittaohjelma saattaa huomata pakkauksen purkamisen (on olemassa Windows API:ita, jotka voivat ilmoittaa tästä ja kutsua haittaohjelman ”koukkutoimintoa”). Sitten riittää, että kopioidaan tietyn niminen DLL-tiedosto TEMP-kansioon (koska tämä on suojaamaton, tämä on mahdollista rajoitetuilla käyttäjäoikeuksilla).
- Asennusprosessin aikana asennusohjelma yrittää ladata oletetun Windows-DLL:n, mutta käyttää haittaohjelman sijoittamaa DLL:ää Windowsin ominaisuuksien vuoksi. Ja haittaohjelma saa DLL:n kautta välittömästi järjestelmänvalvojan oikeudet.
Tämä tunnetaan jo pitkään nimellä DLL:n hakujärjestyksen kaappaus, joka on potentiaalinen tietoturvariski ja jota tulisi ehdottomasti välttää. Stefan Kanthak on lähettänyt joitakin linkkejä ja lisätietoja saksalaisessa kommentissaan. Johtopäätöksenä:
Lisäys: Tässä vaiheessa minun on vetäydyttävä hieman taaksepäin. Vilkaisin asennusohjelmaa (Windows 7:n alla). Mielenkiintoinen havainto: Saksalainen lukija Martin Feuerstein oli huomauttanut kommentissaan, että .exe-asennusohjelmassa on kytkin .msi-asennusohjelmien purkamista varten – voidaan näyttää /? Voit siis purkaa .msi:n ja asentaa 32-/64-bittisen version .msi-asentajan kautta.
On toinenkin havainto: Ilmeisesti .exe-asentaja toimii purkamisen aikana vain tavallisilla käyttäjäoikeuksilla, purkaa .msi-tiedostot ja kutsuu sopivaa. .msi-asentaja aktivoi UAC-kehotuksen manifestissaan olevien asetusten takia ja asentaa työkalun. Tämä eliminoi edellä kuvatun hyökkäysvektorin tämänhetkisen tietämykseni mukaan (sen, kutsuuko oikea msi oikeaa UAC:ta, voi tarkistaa UAC-kehotteesta). Jos tulee uusia havaintoja, lisään ne.
Lisäys 2: Stefan Kanthakin mukaan ClassicStartSetup_4_4_109.exe -asennusohjelmalla on seuraavat riippuvuudet – voidaan hankkia seuraavalla ohjelmalla:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_4_109.exe
COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll
Ja edellä mainitut DLL:t riippuvat GDI32.dll:stä, MSVCRT.dll:stä, RPCRT4.dll:stä, SECUR32.dll:stä ja
SHLWAPI.dll:stä. Koska Windows Vista VERSION.dll ei ole ”tunnettu DLL” ja mikä tahansa tämän niminen tiedosto ladataan sovelluksen hakemistosta, jos se on olemassa. Sama koskee SECUR32.dll:ää ja RPCRT4.dll:ää.
Huomautus: Alla olevissa kuvakaappauksissa ja esimerkkikomennossa käytän vanhempaa ClassicStartSetup_4_4_109.exe-tiedostoa. Tein samat testit myös OpenShellSetup_4_4_126.exe:llä (uusin nightly build) – sama tulos. Myöskään digitaalista allekirjoitusta ei ole saatavilla. Siksi annan vanhat kuvakaappaukset ja komennot tekstin sisälle.
Stefan Kanthak antoi minun käyttää joitakin testidl:iään ClassicStartSetup_4_4_4_109.exe:n suorittamiseen testiympäristössä. Tässä on tulos:
(Klikkaa zoomataksesi)
Yritys näyttää asetukset johti varoitukseen, että haittaohjelma on voinut manipuloida tiedostoja (valintaikkuna edessä). Sen jälkeen annoin .exe-asennusohjelman vain purkaa .msi-asennusohjelmat. Kun suoritin 64-bittisen msi-asennusohjelman, varoituksia ei enää tullut.
Mutta .exe-asennustiedoston sisältämät .msi-tiedostot eivät ole tällä hetkellä digitaalisesti allekirjoitettuja. Syy: Ne ovat yöllisiä versioita. Tässä vaiheessa lopetin jatkotutkimukset. Yölliset buildit eivät ole loppukäyttäjien järjestelmiä varten. Odotellaan, miltä tuon työkalun lopullinen versio näyttää ja onko siinä samoja haavoittuvuuksia kuin edellä on esitetty.
Advertising