Mitigating Buffer Overflow Attacks in Linux/Unix

A buffer overflow is the most common and the most serious threat to Linux/Unix operating systems. Buffer overflows occur when code running in unprotected memory in a buffer overwrites memory in an adjacent location. For example, a string of information, say 20 bytes, is sent to a 16-byte buffer, which can’t accommodate that string. Linux/Unix is written in C and there are memory-safety issues to consider, it could occur as a result of programming errors if memory boundary checking is inefficient or if boundary checking in a process isn’t present.

Buffer overflow becomes a security issue when an attacker manages to maliciously insert code into the memory of a running process, the attacker may then be able to acquire the privileges of that process. Generally buffer overflow is stack based where malicious code placed on a stack changes the return pointer and consequentially program flow, and heap based where overflowing buffers on lower parts of the heap result in unpredictable effects on the rest of the heap.

When trying to prevent buffer overflow, there are few preventative measures you can take. Of course, careful programming should ensure that attackers aren’t made aware of where privilege processes are running from. So analysis of source code for potential vulnerabilities is highly recommended. However, given that programmers are human, buffer overflows are always going to be a problem.

It’s important to disable stack execution and randomize stack location because this will make it more difficult for attackers to locate overflows and inject malicious code. When possible, if you are writing programs, use languages that have memory protection features, for example, Java or C#.

In C and C++, there are no automatic bounds checking on the buffer, which means a user can write past a buffer. For example:

                      int main () {

                     int buffer[10];

                    buffer[20] = 10;

                     }

The above C program is a valid program, and every compiler can compile it without any errors. However, the program attempts to write beyond the allocated memory for the buffer, which might result in unexpected behavior.

It’s always a good idea to perform runtime checking to ensure that buffer overflow isn’t occurring. In certain operating systems, you can enforce stack protection. With stack protection, you can modify your kernel to ensure that code only executes from areas of memory that you have cordoned off and locked. If a malicious user attempts to insert code into the stack-protected memory of a running process, the process will abort. Service will be denied, but the system won’t be compromised. The methods vary depending on the distribution of Linux/Unix or Linux that you are using.

Mac OS X Security Keychain

The keychain is a secure database store for passwords and certificates and is created for each user account on Mac OS X.  The system software itself uses keychains for secure storage.  The “login” keychain is the default location for user credentials and should be protected, while the keychain is unlocked all passwords in the keychain can be exported.  The login keychain should be locked when the system sleeps or after long periods of inactivity.

Changing your keychain password

When a keychain mismatch occurs, the user must change their keychain password to match the password used to log on to the machine.  To correctly change your keychain password, the user will use the application Keychain Access.  Keychain Access is located in Applications\Utilities.

Change your keychain password:

  1. Select “login” under the list of keychains.
  2. From the menu at the top of the screen, click Edit.
  3. Select Change Password for Keychain “login”…
  4. Enter the current keychain password.  Remember that the “current” keychain password is the password previously used to log into the machine, before your most recent password change.
  5. Enter your new password and verify.  The new password you enter should match the password you used to log into the machine.

SSD Encryption from Crucial and Samsung is not secure Exposes Data

Carlo Meijer and Bernard van Gastel, two researchers at Radboud University in the Netherlands issued a warning that hardware encryption in various models of Solid State Drives (SSDs) are not secure.  The vulnerabilities only affected “ATA security” and “TCG Opal hardware-based encryption on SEDs.  Furthermore, it affected the hardware-based encrypted SSD models with a local built-in chip, separate from the main CPU.

The researchers examined multiple SSDs, including Crucial and Samsung, some of which they found could be unlocked with any password if the password validation routine in RAM was modified through a standard JTAG debugging interface.

The two stated that the SEDs they’ve analyzed, allowed users to set a password that decrypted their data, but also came with support for a so-called “master password” that was set by the SED vendor.

They stated,

“Any attacker who read an SED’s manual can use this master password to gain access to the user’s encrypted password, effectively bypassing the user’s custom password”.

Other issues are detailed in the researchers’ paper, titled “Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs),” which can be downloaded in PDF format from here.

Due to limited access to SSDs, Meijer and van Gastel said they’ve only tested their findings on a small number of devices, listed in the table below, but found that all were vulnerable.

Both Crucial and Samsung whose products they’ve tested have released firmware updates to address the reported flaws.

Information Commissioner Calls for Regulation of Social Media Following Cambridge Analytica scandal

An interesting article by Tom Reeve on scmagazineuk.com:

The Information Commissioner Elizabeth Denham has published a report into the the use of data analytics for political purposes at the same time as appearing before the Parliamentary DCMS committee today.

Appearing alongside her deputy commissioner James Dipple-Johnstone, Denham was testifying on “Disinformation and ‘fake news'” before the Digital, Culture, Media and Sport Committee (DCMS), chaired by the MP Damian Collins.

The report into data analytics and political campaigning, which runs to 113 pages, is the culmination of “the largest investigation of its type by any Data Protection Authority,” the report says. It involved social media platforms, data brokers, analytics firms, academic institutions, political parties and campaign groups.

The report is a summary of its findings – more details will emerge in any regulatory notices which are issued by the Information Commissioner’s Office (ICO).

Read the rest here.

Ruby2.3 Security Update – CVE-2018-16395 CVE-2018-16396

Security fix in Ruby on Rails

Several vulnerabilities have been discovered in the interpreter for the Ruby language. The Common Vulnerabilities and Exposures project identifies the following problems:

CVE-2018-16395    

Tyler Eckstein reported that the equality check of    OpenSSL::X509::Name could return true for non-equal objects. If a    malicious X.509 certificate is passed to compare with an existing    certificate, there is a possibility to be judged incorrectly that    they are equal.

CVE-2018-16396    

Chris Seaton discovered that tainted flags are not propagated in    Array#pack and String#unpack with some directives.

For the stable distribution (stretch), these problems have been fixed inversion 2.3.3-1+deb9u4.

We recommend that you upgrade your ruby2.3 packages.

For the detailed security status of ruby2.3 please refer to its security tracker page at:https://security-tracker.debian.org/tracker/ruby2.3

Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/

UK’s Information Commissioner’s Office (ICO) Slap Fines on Facebook and Equifax

UK fines Facebook £500,000 for failing to protect user data

Facebook was fined £500,000 by the UK’s Information Commissioner’s Office (ICO) for its role in the Cambridge Analytica data scandal which allowed unauthorized access of 87 million user information without sufficient consent.

The fine forced by the ICO was calculated using the UK’s old Data Protection Act 1998 which can impose a maximum penalty of £500,000 which represents a small fee for a company that brought in $40.7bn (£31.5bn) in global revenue in 2017.  The penalty could have been much larger had it fallen under EU’s General Data Protection Regulation (GDPR), where a company could face a maximum fine of 20 million euros or 4% of its annual global revenue, whichever is higher, for such a privacy breach.

The investigation found that Facebook failed to keep the personal information of its users secure by failing to make suitable checks on developers using its platform.

Equifax recently faced a similar fine of £500,000 from its massive data breach that exposed personal and financial data of hundreds of millions of its customers.