User Consent not being enforced for SoL over MPS API while in CIRA CCM Mode

[scottmbaker]

I wrote a command line tool that establishes an SoL session, and connected it to DMT release 2.32.0, with a NUC activated in CIRA CCM mode. What I have observed is that while consent is being enforced when I use the DMT GUI, it is not being enforced when I interact with MPS over the API from my CLI tool. That is, I'm able to open an SoL session on the CCM-activated NUC without being requested to enter a consent code, and without the consent popup on the NUC's console.

My CLI interacts with DMT at the URL https:///mps. The CLI basically does the following:

• Retrieves a JWT
• Uses the JWT to retrieve a redirection token
• Builds a relay URL
• Sets up a websocket connection to stdin, where the user may then interact over the SoL to the NUC

The CLI is a small Go program, not quite as simple as a bash script, but I can provide the source if that would be helpful. Below is the amtinfo from the NUC:

$ sudo ./rpc amtinfo
Version : 16.1.35
Build Number : 2557
SKU : 16392
Features : AMT Pro Corporate
UUID : (redacted)
Control Mode : activated in client control mode
Operational State : enabled
DNS Suffix : vprodemo.com
DNS Suffix (OS) : scott-demo
Hostname (OS) : scott-demo
RAS Network : outside enterprise
RAS Remote Status : connected
RAS Trigger : periodic
RAS MPS Hostname : (redacted)
---Wired Adapter---
DHCP Enabled : true
DHCP Mode : active
Link Status : up
AMT IP Address : 0.0.0.0
OS IP Address : (redacted)
MAC Address : 88:ae:dd:71:5d:23
---Wireless Adapter---
DHCP Enabled : true
DHCP Mode : passive
Link Status : down
AMT IP Address : 0.0.0.0
OS IP Address : 0.0.0.0
MAC Address : 00:00:00:00:00:00

Scott

[graikhel-intel]

Thanks for sharing the details, this behavior is expected and is not a security issue.

SOL itself does not require user consent in CCM. What does require user consent is actions such as rebooting into BIOS or changing boot behavior. More information about AMT user consent behavior is available here:

https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fuserconsent.htm

https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm?turl=WordDocuments%2Fuserconsent1.htm

So in this case, the fact that your CLI can establish an SOL session through MPS without triggering a consent popup is consistent with how AMT behaves. The difference you’re seeing is likely because our UI is currently asking for consent too broadly (or early), even when the actual SOL connection itself does not require it.

I think the fix on our side is likely a UI behavior change --- Do not require or prompt for user consent when starting a plain SOL session. Only show the consent flow when the user initiates an action that actually requires it, such as Reset to BIOS.

Would love to check out the tool as well. I do think SOL has a lot of potential for automation use cases. One classic example would be rotating BIOS passwords without requiring any manual intervention.