Securing your Internet-enabled Linux device design

Linux-based systems are increasingly being used in networked devices, as this open source operating system offers a solid POSIX base for API and other conventions, supports a permissions model conducive to a secure system, and has industry-wide support.

Its use makes it much easier to create and remotely manage smart devices for utility services, traffic control, or reading meters, and can have positive application benefits for business and personal use. However, there are some drawbacks, especially in consumer electronics, where many “smart products” depend on availability of Linux as an open source operating system to keep the cost of developing and deploying such applications as low as possible, and reduce the development time and get to market faster, an important factor in many Internet-enabled consumer electronics devices.

But as with other widely deployed operating systems in consumer computing applications ranging from Android-based mobile devices to Microsoft Window-based desktops, laptops, and now mobiles, the Linux OS is an attractive target for hackers. In addition, product designers and manufacturers of Linux-based designs are always looking for ways to lower the cost of development or improve economies of scale. One way to do that is to do what is politely called “product de-scoping”, which can adversely affect device security.

This is a dangerous strategy in a market for Internet-enabled consumer products where hackers have already proven that Wi-Fi light bulbs, baby monitors, and even pacemakers can be vulnerable to attack. While the roll-out of smart meters will enable energy companies to make significant operational cost savings, it is possible that hackers could find a way to switch all of the meters off, leaving thousands of homeowners and businesses without energy in a widespread Denial of Service.

Not only would the damage to a company’s reputation be enormous but the costs of addressing the issue would be even more significant than the savings that had been generated. The security breach would need to be identified, solutions determined (for immediate fix and a more permanent solution, if required) and customers would need to be reconnected, as safety standards require each meter to be switched on manually (necessitating an engineer’s visit)!

At best this may cause a few customers minor issues; at worst, it could cut energy to millions of customers and jeopardize the business. But it’s not just organizations designing and developing devices with embedded systems who should pay attention to securing their Internet-enabled designs. Many thousands of enthusiasts and students are looking to put their own Linux-based devices online – and they can be just as vulnerable.

Every program is a potential target. Vulnerabilities can be found and used to crash your software, learn your secrets, steal your passwords and financial date, or gain control – whether that’s to show off or to use your product maliciously Therefore, it makes sense to build in security from the start.

This article is aimed at anyone who is developing an Internet- enabled Linux device for personal or business use. It highlights the main areas to consider and provides a practical checklist for developing secure applications for Embedded Linux.

First, we will look at the various security layers in a Linux system, then at the ways such systems can be hacked, and finally provide you with a check list of 25 tips to follow to be sure the application you are developing is protected.The Linux security onion
There are various layers that need to be considered in the ‘Linux security onion’ (Figure 1 ).

  • The network layer – the connected environment such as the internet or IoT
  • The environment layer – the Linux operating system
  • The application layer – the device’s physical system, code and application scripted onto the device by the developer

Figure 1: The Linux security onion

Securinga device means understanding how and why problems occur and how toaddress each of these specific layers. For example, C and C++ are notsecure languages. They can be subject to format string attacks, bufferoverflows, or stack and heap overflows – but they are the de factochoice for development on Linux.

Even using a high level languagesuch as Python does not mean that developers can be complacent andassume they are safe from malicious actors. Developers need to take moreeffective action to secure their devices online.

There areseveral ways that a device can be hacked. One of these is to trick thedevice into consuming more input than it allocated memory for, to cause abuffer overflow. Once the buffer that lives on the program overflowseither:

  • the stack is ‘smashed’. This allows an overwrite to another stack variable which can be used to take control of the device – often by aiming the CPU at memory you don't control; or
  • the heap is corrupted by fooling the system about how it tracks memory. Once corrupted, it is possible to trick the program into writing to arbitrary places in the memory.

Authentication and best practice suggestions
Belowis a check list of 25 tips relating to authentication, softwarearchitecture, and language, coding, and file path issues for developersto follow if they want to secure the application layer in the Linuxsecurity onion.

Tip #1. Use an authenticationmechanism that cannot be bypassed or tampered with. When implementingauthentication, ensure that it cannot be bypassed trivially – hardcodedpasswords often cause issues, as well as “secret” admin pages forweb-enabled devices where you only need to know the URI.

Tip #2. Make sure you authorize after you authenticate. Understand thedifference between authorization and authentication and what that meanson your platform: Authorization is what the user can do(discretionary/mandatory access controls, read/write access to files,etc). Authentication is who the user is (username + SSH keys/password).

Tip #3. Strictly separate data and control instructions, and never processcontrol instructions received from untrusted sources. If you requireprivileged status to perform functionality, separate the reading/writingof the raw data from the parsing/logic. This prevents bugs and exploitsin the data processing side (think XML, JPEG, etc.) from interferingwith the control logic. This is paramount when handling data fromunverified sources.

Tip #4. Define an approach thatensures all data is explicitly validated and identify sensitive dataand how it should be handled. Always validate and verify the filesentering your system. If you're processing an XML file that consists of amillion nested elements, what will happen to your parser? Consider averification/fuzzing strategy and assume hostile intent.

Tip #5. Understand how integrating external components changes your attacksurface. The more components added to your system, the larger yourattack surface. Think about what happens if you add USB support — dobugs in the USB stack open you up to unexpected strategies? What aboutuserspace applications? Consider these effects when competing in thefeatures race.

Tip #6. Be flexible when consideringfuture changes to objects and actors. Take the view that some of thesoftware on your platform will have flaws and it may not always be inthe controlled conditions it was originally designed for. Alwaysconsider an upgrade/patch strategy for your embedded devices.

Tip #7. Use “safe” string functions. For example, avoid ‘strtok’ and use‘strtok_r’ or ‘strtok_s’ with – std=c11 instead, in order to preventbuffers being modified or performing ‘out of character.’

Tip #8. Always know the size of the string and allocate a string large enough to hold the output, including NULL

Tip #9. Be wary of NULL and control characters in data you're handling.

Tip #10. Know the memory model – who allocates and who frees, the caller or the callee?

Tip #11. Always allocate enough memory for the expected input and watch out for magic numbers or out of range values.

Architecture and data tips
Tip #12. Knowing how your architecture works is fundamental to understanding howit can be used against you. Sometimes it can be fun to have a“breakdown session” to see how secure your product is.

Tip #13. Shellcode isn't that hard to write … when you know how. Take some time to learn how to read it and how it works.

Tip #14. The GNU debugger (GDB) and objdump are free and highly powerful tools – learn how to use them to understand not what your code should do but what it can do.

Tip #15. New exploit techniques are always being developed. Stay on top of them by tracking the Common Vulnerabilities and Exposures (CVE) lists and ensure that you have an update strategy.

Tip #16. Always check what data you're being given – e.g., gif/jpeg/mp3/wav etc.Do you trust the values given to you? What does your code do when itopens a JPEG that's -100000 by -1000000?

Language, file paths and other coding tips
Tip #17. C and C++ are not secure languages so remember to do formalverification when using them – bonus points if it's part of yourcontinuous integration strategy.

Tip #18. Even understanding how an executable binary gets into memory in the first place will give you an advantage over other programmers.

Tip #19. Try not to harden code values – what if you update in one location and not the other?

Tip #20. Remember that all command line arguments are in control of the userlaunching it. Are you using getopt or have you rolled your own? Is itsecure?

Tip #21. Be careful about working with shared files. Who else can read/write to the file?

Tip #22. Filepaths can contain directory traversal attacks, so be wary of them.

Tip #23. Think about file operations. For example, try to avoid API calls thattake a path name and prefer those that take a file descriptor instead –this will help mitigate race conditions. And watch out for hard/softlinks.

Tip #24. Don't be afraid to use open-source libraries. Most are under the GNU Lesser Public License (LGPL), which allows dynamic linking without requiring you to open-source your code.

Tip #25. Learn what tools are available for your environment. if you aren'twilling to discover them, there's a hacker or saboteur who will!

Don’t just ship it – understand it!
TheInternet of Things (IoT) offers endless possibilities for smart devicesand their applications. So it’s no wonder that the IoT is equallytempting to hackers as it is to developers keen to showcase their latestdevelopments. A lack of current issues doesn't mean you're OK. You'reprobably just not being targeted yet.

Following these 25 tips forsecuring the Linux application layer should help you to define anapproach that ensures your data is explicitly validated, the software iswell written, and as a result, you are more confident in the securityof your device.

Of course, there is much more a developer can doto ensure that a Linux- based device has greater security online.Essentially, the more you know about your product the more you cansecure it.

Nick Glynn has a background in embedded software and began his career at Intel. He joined Feabhas in 2012 and is responsible for developing and delivering coursematerial for Linux-based training on Kernel/User space and the Androidplatform in the UK and across the globe. This includes the recentlylaunched Secure Linux Programming course . Nick is also a Consultant on Linux/Android strategies in the embedded space.

References

1. Avoiding the top ten software security design flaws  (IEEE 2014)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.