Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
2x a month. No spam.
November 9, 2021 - TuxCare PR Team
Iconv is a library used to convert between different character encodings and is part of a core group of tools and libraries used to perform basic level tasks called glibc (GNU C Library). According to the venerable glibc documentation, it enables the conversion of characters between 150 different character sets.
During regular work on TuxCare’s Extended Lifecycle Support (ELS) service, where patches are created or backported to older Linux distributions that are past their end-of-life date, the team identified a previously unknown vulnerability in a code path inside iconv. But, of course, finding the bug is just half the work, so a fix was also developed and submitted upstream.
Patches for systems covered by ELS are already available for deployment.
The actual vulnerability happens when a specific conversion is triggered; namely, a conversion from ISO-2022-JP-3 could cause a spurious NUL character to be emitted. This could be trivially triggered by passing an escape sequence that switches the active character set. Depending on the use case, an extra NUL character received by a caller application could cause data corruption or inconsistent behaviour.
This bug was introduced as part of Bugfix 27256, as this check:
that was added by that bugfix behaves as if ‘�’, the NUL character, is queued and proceeds to emit it in the output.
When asked if he thought that the bug was currently exploitable, Nikita Popov, the team member behind the discovery, commented, “This case can be caused by a special use pattern of glibc. This is somewhat similar to our previous bug (and is native to all libraries due to their nature: a shared library is as vulnerable as a host application being unlucky enough to utilize an unfortunate set of library calls in a specific sequence).”
This is another of TuxCare’s contributions to upstream projects and also another vulnerability identified by the same team member, following one identified in glibc some weeks ago.
In keeping with industry best practices on responsible disclosure of vulnerabilities, upstream developers were notified. Additionally, a patch to correct the underlying issue was also submitted to the appropriate project repository. Because of the security implications implicit in an issue that can potentially cause data integrity problems, a CVE was requested and assigned, CVE-2021-43396. The existence of a CVE entry should hasten the incorporation of the fixed version in widespread Linux distributions.
Redhat already assigned a 7.5 CVSS v3 base score while assessing its impact on RHEL 6 to 8. NIST also assigned a 7.5 score, meaning that the vulnerability has a High risk/impact. Vulnerability prioritization for patching operations should take this information into account when preparing upcoming maintenance windows.
The ever-growing number of vulnerabilities found is a visible aspect of more and more researchers and developers going over the code – open-source code. While more vulnerabilities tend to mean more work for IT teams, the upside is that finding these issues before they are actually exploited is the best possible outcome.
The TuxCare Team will continue its work ensuring Linux distributions old and new are kept secure, with a strong commitment to open source and upstream projects.
If you would like to know more about TuxCare, its Extended Lifecycle Support service or Linux Support Service, you can find details here.
[Update 11/11 – In the interest of transparency, the status of the CVE is being disputed. While the bug has been acknowledged and the fix solves the issue, the attack vector required to exploit this is mentioned as being application-specific – the application calling iconv would have to pass the values in a specific order – rather than iconv-specific. You can find more information about this in the CVE description here https://nvd.nist.gov/vuln/detail/CVE-2021-43396. This is an example of the review process around bug submission working in the open source ecosystem. This post will be updated with further developments if/when they happen.]
Learn About Live Patching with TuxCare
Look, everyone knows that it’s a tough act. Thousands of...
The public sector, including state and federal agencies, are at...
If your organization deploys IoT solutions, you know that development...
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...
In a symphony orchestra, instruments harmonize to create one pleasing...