This week, we’ll cover a couple of high-severity vulnerabilities, one in Rubygems and another in Rsyslogs. We will also discuss the importance of defining secure coding practices.
Unauthorized gem Takeover in Rubygems
Rubygems is a package registry used to supply software for the Ruby language ecosystem. Due to a bug in the yank action, it was possible for any RubyGems.org user to remove and replace certain gems even if that user was not authorized to do so.
To be vulnerable, a gem needed:
- One or more dashes in its name
- An attacker-controlled gem with the name before the dash
- Creation within 30 days OR no updates for over 100 days
Mitigation
According to the Bundler team, using Bundler in –frozen or –deployment mode in continuous integration and during deployments will guarantee that your application does not silently switch to versions created using this exploit.
To audit your application history for possible past exploits, review your Gemfile.lock and look for gems whose platform changed when the version number did not change. For example, gemname-3.1.2 updating to gemname-3.1.2-java could indicate a possible abuse of this vulnerability. RubyGems.org has been patched and is no longer vulnerable to this issue.
Potential Heap-based Buffer Overflow in Rsyslogs
Rsyslog is a rocket-fast system for log processing. Some modules for TCP syslog reception have a heap buffer overflow when octet-counted framing is used. In “octet-counted” framing, each message is prefixed with the actual message length, so that a receiver knows exactly where the message ends. The attacker can corrupt heap values, leading to data integrity issues and availability impact. Remote code execution is unlikely to happen but not impossible. Versions 8.2204.0 and lower are affected by this vulnerability.
Mitigation
Octet-counted framing is not very common. Usually, it needs to be specifically enabled at senders. If users do not need it, they can turn it off for the most important modules. This will mitigate the vulnerability. How to do this depends on the module. Refer here for affected modules and configuration details based on modules. The patch is available in version 8.2204.1.
The Importance of Defining Secure Code
Secure coding is the practice of skilled developers writing code that is free from vulnerabilities from the start of the Software Development Lifecycle (SDLC). Only once this practice is defined can the developer community work towards that goal. Secure Code Warrior conducted The state of developer-driven security survey, 2022 in partnership with Evans Data Corp in December 2021, surveying 1,200 developers globally to understand the skills, perceptions, and behaviors when it comes to secure coding practices, and their impact and perceived relevance in the SDLC.
Here are some highlighted points from the survey:
- Out of 1,200 only 14% of the active software developers put secure coding as their top priority.
- 37% of developers in the survey reported leaving known vulnerabilities within their code because tight deadlines would not allow for the time needed to fix them or to code properly from the start.
- 36% of survey respondents also said they wanted to remove vulnerabilities from their code but didn’t have the skills or the knowledge to do so.
- The problem in many cases for developers to write secure code is that the organizations they work for have not identified what best practices are required to produce secure code and have not put enough resources into training or enabling their developers to meet those goals.
So along with proper definition of what secure coding practices are, organizations also need to provide longer deadlines giving developers enough time to properly code and provide hands-on training that helps them identify and fix code vulnerabilities efficiently.
You can get more detailed information on the survey here.
Comments