1
0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-09-19 17:24:43 -04:00

Minor fixes

Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2024-06-10 07:39:03 -07:00
parent 6bb69fe16b
commit 5eddf1992a
Signed by: Tomster
GPG Key ID: 555C902A34EC968F

View File

@ -90,9 +90,9 @@ Here are some facts about it:
- You can disable it firmware settings. - You can disable it firmware settings.
- Certain firmware allows you to permanently disable it by blowing an eFuse. - Certain firmware allows you to permanently disable it by blowing an eFuse.
- It is detectable. An easy way is to just go visit port 16992/tcp on your device. - It is detectable. An easy way is to just go visit port 16992/tcp on your device.
- To be extra sure, you can also run nmap to scan the port from a different device. - To be extra sure, you can also run `nmap` to scan the port from a different device.
This is not a hidden thing at all, people have accidentally [run into it on social media](). This is not something hidden, people have accidentally [run into it on social media](https://mastodon.lilysthings.org/@i_lost_my_bagel/112228352384742242).
For attack surface reduction, you should absolutely disable it. With that said, don't let the scary claims about "remote management" by the Free Software Foundation spook you - if some sort of hypothetical backdoor actually implemented this way, it is not hard to detect. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro model. For attack surface reduction, you should absolutely disable it. With that said, don't let the scary claims about "remote management" by the Free Software Foundation spook you - if some sort of hypothetical backdoor actually implemented this way, it is not hard to detect. There are better ways to implement a backdoor as discussed above, and if you don't trust the CPU vendor you should avoid them as a whole, not just the vPro model.