attachment

<div dir="ltr"><div>Hi Mike,</div><div><br></div><div>Thanks for your good comments here.<br></div><div><br></div><div>All of the current warnings in the Internet Protocol Suite appendix are to</div><div>be moved to appropriate recommendations (with expanded rationales</div><div>and usage limitation suggestions). in section 4 (that's my TODO in the <br></div><div>change log).  <br></div><div><br></div><div>I didn't do any of that yet, because I haven't yet *written* section 4 and I <br></div><div>wanted to do the edits in the appendix based on Smith's IDS review <br></div><div>comment that I should carefully distinguish between the IETF defined <br></div><div>protocols in the IPS and the non-IETF protocols that can be used in the <br></div><div>IPS (e.g., Wi-Fi).</div><div><br></div><div>In automotive systems (where functional safety is paramount), use of</div><div>remote shells is forbidden entirely by both regulations and standards.</div><div><br></div><div>My own intuition is that remote shells should not be used in HCDs</div><div>because, if there is any implementation bug in the shell (e.g., SSH),</div><div>then a privilege execution attack becomes easy to implement.  Do</div><div>you disagree with that recommendation?<br></div><div><br></div><div>Cheers,</div><div>- Ira</div><div><br></div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG</div><div>Co-Chair - TCG Metadata Access Protocol SG<br></div><div dir="ltr">Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>(permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434</div><div>(to 30 April 2020) 203 W Oak St  Ellettsville, IN 47429  812-876-9970<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 4, 2020 at 9:38 AM Michael Sweet via ids <<a href="mailto:ids@pwg.org">ids@pwg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Ira,<div><br></div><div>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:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div><div>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.</div></div></blockquote><div><div><br></div><div>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...)</div><div><br></div><div>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.</div><div><br></div><div>For example:</div><div><br></div></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div><div>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.</div></div></blockquote><div><br></div>and then:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px">9.X Secure Shell (SSH) Considerations</blockquote><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><br></blockquote><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px">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.</blockquote><div><br></div>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.<div><div><br><div><div><div>________________________<br>Michael Sweet<br><br><br></div><br></div></div></div></div></div>_______________________________________________<br>
ids mailing list<br>
<a href="mailto:ids@pwg.org" target="_blank">ids@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ids" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ids</a><br>
</blockquote></div>