Schneier on Security

Nick P • March 12, 2013 2:58 PM

Stories like this used to excite me. Truly though, this kind of thing is pretty basic: it runs on an OS that has problems; turn a problem into an exploit; give it some extra (common) malware features. It takes skill but it’s exactly what people should expect would happen to these IP phones.

Now, their symbiote work is really clever and took a lot of thinking. I kind of slammed it in the past for it’s weaknesses (below). That said, I like radical approaches b/c they sometimes lead to breakthroughs. I look forward to seeing how their symbiote system evolves.

http://www.schneier.com/blog/archives/2013/01/friday_squid_bl_358.html#c1073275

Nick P • March 14, 2013 12:33 AM

@ mishehu

” How is a web server REALLY that more of a security hole than an SSH daemon, or anything else that is accessible by the network? I’d assert that pretty much anything that is open is also open for attack.”

The use case was said to be configuration or debugging. Web servers are often complex and increase the TCB. Sending data from one machine to another doesn’t require a web server. It can be done with a simple text- or binary format, UDP, and a simple auto-generated parsing system. These can be implemented in a rigorous way with little effort. Have been, if you consider DO-178B and INRIA’s work. Secure web servers, on the other hand, are still an open issue all around.

” If you’re serious about security, I’d first secure the streams using ZRTP (http://zfoneproject.com/) or a product that uses Phil Zimmermann’s ZRTP implementations.”

I agree. I’ve used VOIP over Secure IP, OpenVPN SSL, ZRTP, the Cryptophone protocol, and handrolled solutions. There’s quite a few options when someone demands encrypted calls. The issue at hand is many managers or users think they bought at phone that plugs into IP networks. They actually bought a mini-PC that does plenty of other stuff & is easy to subvert.

” But I’d rather have some basic functionality available out of the box that I can then later disable (i.e. if I switch to a centralized provisioning model).”

That’s quite sensible, esp. from a business perspective. I allowed for it in my previous comment. The difference is that I promote secure by default, meaning it would be off by default. It would also be easy for legitimate owner to enable it. I also promote the use of compartmentalization in special purpose devices, like using MAC or MILS. Stopping the web server functionality from being a step in a series of advances might be infeasible. However, limiting it to network and config file access using existing software isolation techniques would give users the benefits while greatly reducing the risk.

One can often get far with small steps.

@ Paul

“True, it’s probably not necessary, but in my experience the feature can be very convenient (although configuring and troubleshooting IP phones is my day job, so I have more cause to use the web interface than most admins would).”

Totally. In my designs, I let the interface be whatever people want it. What get’s sent down the wire and interacts with the network is quite simple. That data doens’t need to be human readable, the protocol is immaterial, etc. The middle layer does all that. So, you get the security benefits of simpler stack on the embedded device and a convenient interface on the admin end.

” I’d really rather not have to install a custom client per phone vendor that I work with, and how do we even know they’d implement the client correctly?”

There’s where the inconvenience will appear. Modern development tools make it easy to code a configuration tool that’s a single executable. There’s also RAD tools that can automate some of it. This is one of the easier types of programs to do correctly. If anything the companies are more likely to screw up on the user interface design. Also, different vendors will do different things. (But that happens anyway for web configuration, right?)

My approach might imply a solution to the problem you mention. The approach calls for a simple, M2M transport system. It would inherently be in a separate module from the actual interface. So, if you wanted, you could actually roll your own using whatever technology or layout you chose. A third party or open source product might provide integrated management of vendors’ products. So, your conveniences are still possible, but the VOIP device has less complexity.

“A lot of service providers fail to realise that if one phone gets owned, they could be on the hook for tens or even hundreds of thousands of dollars worth of fraudulent calls.”

In the dialup era, it was 900 numbers dialing to Nigeria and other places. Those 900 operators let the crooks use their service for around a 30% cut. Many didn’t work if people’s PC modems were unplugged when not online. There were more effective solutions, but this slightly inconvenient and simple one save quite a few users big money. Convenience vs risk is a recurring tradeoff.

Nick P • March 14, 2013 11:53 AM

@ mishehu

” I suspect you would have less reservations if they put the most simplistic and secure web server there. Something akin in spirit to vanilla Qmail for security (and equally as limited in functionality).”

I see you’re getting the idea. 😉 Further with that idea, there are quite a few managed languages that have web serving libraries. This can eliminate most code injection attacks while raising the developer’s productivity.