Hi Mike,
Thanks for your good comments here.
All of the current warnings in the Internet Protocol Suite appendix are to
be moved to appropriate recommendations (with expanded rationales
and usage limitation suggestions). in section 4 (that's my TODO in the
change log).
I didn't do any of that yet, because I haven't yet *written* section 4 and
I
wanted to do the edits in the appendix based on Smith's IDS review
comment that I should carefully distinguish between the IETF defined
protocols in the IPS and the non-IETF protocols that can be used in the
IPS (e.g., Wi-Fi).
In automotive systems (where functional safety is paramount), use of
remote shells is forbidden entirely by both regulations and standards.
My own intuition is that remote shells should not be used in HCDs
because, if there is any implementation bug in the shell (e.g., SSH),
then a privilege execution attack becomes easy to implement. Do
you disagree with that recommendation?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
(to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970
On Tue, Feb 4, 2020 at 9:38 AM Michael Sweet via ids <ids at pwg.org> wrote:
> Ira,
>> Sorry, I guess I forgot to re-subscribe to the IDS list post-Apple, but I
> have some issue with the following text in section 12.7.17 on SSH:
>> Note: SSH is inherently dangerous, because implementation or configuration
> errors can allow privilege escalation and unconstrained remote shell
> capabilities on target systems. SSH has major security flaws and has often
> been used for widespread Internet attacks by intelligence agencies and
> criminal organizations. Therefore, SSH is unsuitable for use in any HCD.
>>> SSH is an Internet Standard and is IMHO the only viable solution for a
> remote "shell" interface. Honestly I wouldn't want any vendor to try to
> invent their own "secure" solution (you know what happens then...)
>> I would much prefer that the PWG talk about *what* the actual security
> considerations are and not focus on historical issues that have a) been
> fixed and b) affected specific implementations of SSH and not the protocol
> itself.
>> For example:
>> Note: The Secure Shell protocol is a common target for exploitation by
> malicious actors. See section 9.X for a discussion of the security
> considerations of providing an SSH service on an HCD.
>>> and then:
>> 9.X Secure Shell (SSH) Considerations
>>> HCDs that provide a SSH service MUST NOT enable a common default password
> and MUST restrict the commands that can be executed to those needed for
> maintenance of the HCD that cannot be supported through other standard
> protocols.
>>> We can debate what the full text should be, but IMHO the focus should be
> that a) SSH is a common target, b) SSH (like all HCD software) needs to be
> updated to address security issues, and c) SSH should not provide general
> access to the device. Ideally it shouldn't be needed, but some HCDs are
> complex enough that a service tech might need to dig a bit to configure/fix
> things.
>> ________________________
> Michael Sweet
>>>> _______________________________________________
> ids mailing list
>ids at pwg.org>https://www.pwg.org/mailman/listinfo/ids>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20200204/658bfd2c/attachment.html>