You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This update method currently accepts arbitrary firmware from the root user (or any user with IPMI node access privileges) and relies on a vendor signature check to screen out malicious uploads. Within the framework of our trustless system design (i.e. we had over full system control to the end user, and do not utilize a master vendor signing key) this means anyone with IPMI node access can compromise the end user system, unless the end user is able to set up a key-based authentication system prior to use.
Needless to say, the requirement to access the BMC over the network (non-local) in order todo initial configuration of the updater signing keys somewhat lessens the overall utility of the host-local update mechanism.
It would be useful to add an optional (compile time option) BMC authentication step prior to, or in conjunction with, accepting the uploaded firmware This could take the form of e.g. a third authentication file with the BMC root password and the firmware hashes, or a post-upload challenge step where the BMC sends the computed firmware hashes to the host for validation, and requests the BMC root password as a challenge prior to applying the updates. The former is somewhat simpler to implement, and would seem to provide a similar overall security footprint provided the update daemon transmits the password and hashes to the BMC without relying on an external user-provided file or temporary file.
This proposal would move authentication back into the BMC's well established, owner-controlled user management systems instead of relying on a vendor signing key as the sole check against malicious firmware upload.
The text was updated successfully, but these errors were encountered:
This update method currently accepts arbitrary firmware from the root user (or any user with IPMI node access privileges) and relies on a vendor signature check to screen out malicious uploads. Within the framework of our trustless system design (i.e. we had over full system control to the end user, and do not utilize a master vendor signing key) this means anyone with IPMI node access can compromise the end user system, unless the end user is able to set up a key-based authentication system prior to use.
Needless to say, the requirement to access the BMC over the network (non-local) in order todo initial configuration of the updater signing keys somewhat lessens the overall utility of the host-local update mechanism.
It would be useful to add an optional (compile time option) BMC authentication step prior to, or in conjunction with, accepting the uploaded firmware This could take the form of e.g. a third authentication file with the BMC root password and the firmware hashes, or a post-upload challenge step where the BMC sends the computed firmware hashes to the host for validation, and requests the BMC root password as a challenge prior to applying the updates. The former is somewhat simpler to implement, and would seem to provide a similar overall security footprint provided the update daemon transmits the password and hashes to the BMC without relying on an external user-provided file or temporary file.
This proposal would move authentication back into the BMC's well established, owner-controlled user management systems instead of relying on a vendor signing key as the sole check against malicious firmware upload.
The text was updated successfully, but these errors were encountered: