AMDn ajureissa http-palvelin? (tbaseprovision-service)

[hkultala]

AMDn ajurien mukana tulee service nimeltä "tbaseprovisioning" joka avaa HTTP-palvelimen portissa 8732.

Voi kokeilla ottaa selaimella yhteyttä tähän porttiin, siellä vastaa http-palvelin joka tarjoaa 404sta juuresta, mutta ainakin löytyy tällainen sivu sieltä:

http://localhost:8732/Design_Time_Addresses/RootPA/Service1/


Kun tuon palvelun kytkee pois päältä, tuo www-palvelin ei enää vastaa.



Tosin oman windowsini palomuuri tuntui blokanneen tuon ettei siihen saanut yhteyttä ulkopuolelta.


Todennäköisesti tässä on kyse todella kädettömistä ajurikoodareista AMDllä, eikä tarkoituksellisesta backdoorista, eikä tämän kautta pysty tarkoituksellisesti tekemään mitään "väärää", mutta kaikki ylimääräiset kuuntelevat portit ja palvelinsoftat on aina tietoturvariskejä, erityisesti tällaiset piilossa olevat joita ei todennäköisesti edes aktiivisesti päivitetä kun niitä ei pitäisi edes olla olemassa.


AMD kyllä ansaitsee aika paljon paskaa niskaansa tällaisesta.

 

[Kaotik]

Tuota on vissiin päivitetty postauksesi jälkeen? AMD:n mukaan ei ole missään nimessä mistään backdoorista

Hi, folks. I have to caution against jumping to conclusions on this one.

Our PSP security kernel is not allowing public internet connections. If you netstat port 8732, you will see it's only listening to local loopback connections from the local computer. That said: this is the Tbase security kernel designed to enable remote management of a PC if the user has an app to enable it.

The Tbase kernel authorizes the cryptographic key exchange between one of these trusted apps, a remote authorization server, and the AMD PSP. In essence: "are you really who you say you are?" If you never install one of these trusted apps, there is no remote access.

No such apps exist at this time, and you would be in control of installing/configuring/using/authorizing such an app anyways. Otherwise, the Tbase kernel is what we use to facilitate secureboot for Win10.

 

[hkultala]

Tuota on vissiin päivitetty postauksesi jälkeen? AMD:n mukaan ei ole missään nimessä mistään backdoorista

. If you netstat port 8732, you will see it's only listening to local loopback connections from the local computer.

Tämä ei pidä paikkaansa. portti on bindattu kuuntelemaan 0.0.0.0:8732 EIKÄ 127.0.0.1:8732, katsoin mitä tuo netstat sanoi. Se yrittää kuunnella KOKO MAAILMAA eikä vain paikallisia yhteyksiä. Omalla koneellani tosin windowsin palomuuri (onneksi) blokkasi tuon oletuksena.

Eli ilmeisesti AMD oli AIKONUT laittaa sen kuuntelemaan vain paikallisia yhteyksiä, mutta joku koodari mokasi, ja sen sijasta, että oltaisiin edes tutkittu/varmistettu asiaaa kunnolla kun siitä raportoitiin, kerrottin vaan ulos miten sen PITÄISI TOIMIA että "mitään huolta ei ole" sen sijaan että oltaisiin tarkastettu että se toimii kuin sen pitäisi toimia ja korjattu se.

 

[jive]

tästähän voi nyt sitten vetää foliohattua tiukemmin päähän ja miettiä kyseisen ominaisuuden koodanneen henkilön motiiveja ...

 

[peksi]

tästähän voi nyt sitten vetää foliohattua tiukemmin päähän ja miettiä kyseisen ominaisuuden koodanneen henkilön motiiveja ...

Toki, toisaalta IT-alalla pusketaan hirveän kiireen ja featurepaineen alla ihan tolkuton määrä paskaa ulos joka hetki. Tällaiseen ei edes tarvita mitään erikoisempia motiiveja, vaan lähinnä kädetystä ja toki totaalista reviewin ja QA:n puutetta.

 

[Deussu]

Toki, toisaalta IT-alalla pusketaan hirveän kiireen ja featurepaineen alla ihan tolkuton määrä paskaa ulos joka hetki. Tällaiseen ei edes tarvita mitään erikoisempia motiiveja, vaan lähinnä kädetystä ja toki totaalista reviewin ja QA:n puutetta.

AMD on myös puskenut populaa tasaisesti ulos, joten ei taida kovinkaan moni käydä tyhjäkäynnillä siellä. Kiireinen taho pushaa kiireiselle taholle, joka saattaa olettaa, että hommat on katottu jo lähettävässä päässä ja soppa on valmis.

Näitä aivopieruja ja/tai nukahduksia sattuu paremmissakin piireissä. Tietysti mikään ei oikeuta tuollaiseen, mutta kunhan symppaan tekijöitä.