1
0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2024-11-09 16:21:34 -05:00

More fixes

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

View File

@ -92,7 +92,7 @@ Here are some facts about it:
- 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 something hidden, people have accidentally [run into it on social media](https://mastodon.lilysthings.org/@i_lost_my_bagel/112228352384742242). This is not something hidden, people have accidentally [run into it](https://mastodon.lilysthings.org/@i_lost_my_bagel/112228352384742242) on social media.
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.