Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Safeguarding internet-enabled Linux device design

Posted: 01 Dec 2014     Print Version  Bookmark and Share

Keywords:Linux  POSIX  API  operating system  OS 

Securing a device means understanding how and why problems occur and how to address each of these specific layers. For example, C and C++ are not secure languages. They can be subject to format string attacks, buffer overflows, or stack and heap overflows—but they are the de facto choice for development on Linux.

Even using a high level language such as Python does not mean that developers can be complacent and assume they are safe from malicious actors. Developers need to take more effective action to secure their devices online.

There are several ways that a device can be hacked. One of these is to trick the device into consuming more input than it allocated memory for, to cause a buffer overflow. Once the buffer that lives on the program overflows either:
 • 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
Below is a check list of 25 tips relating to authentication, software architecture, and language, coding, and file path issues for developers to follow if they want to secure the application layer in the Linux security onion.

Tip #1. Use an authentication mechanism that cannot be bypassed or tampered with. When implementing authentication, ensure that it cannot be bypassed trivially—hardcoded passwords often cause issues, as well as "secret" admin pages for web-enabled devices where you only need to know the URI.

Tip #2. Make sure you authorise after you authenticate. Understand the difference between authorisation and authentication and what that means on your platform: Authorisation 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 process control instructions received from untrusted sources. If you require privileged status to perform functionality, separate the reading/writing of the raw data from the parsing/logic. This prevents bugs and exploits in the data processing side (think XML, JPEG, etc.) from interfering with the control logic. This is paramount when handling data from unverified sources.

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

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

Tip #6. Be flexible when considering future changes to objects and actors. Take the view that some of the software on your platform will have flaws and it may not always be in the controlled conditions it was originally designed for. Always consider 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 prevent buffers 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.

 First Page Previous Page 1 • 2 • 3 Next Page Last Page



Comment on "Safeguarding internet-enabled Linux ..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top