Security and software developers are working overtime to patch 7-Zip vulnerabilities. 7-Zip is an open-source compression tool. The recently discovered flaws could provide attackers with the ability to take full control of an operating system. This entry point could be used to infiltrate malware into networks and corporate systems.
7-Zip compression is used by many very popular software and security programs, including products by MalwareBytes and FireEye (though the flaws are not due to the coding of these developers). The vulnerability was discovered by Cisco security expert Jaeson Shultz. He immediately contacted the 7-Zip platform who are confident that the vulnerability has now been closed.
Shultz explained how the flaws could give entry to updated machines and provide the hackers with logged-in user rights of access, “Anytime the vulnerable code is being run by any sort of privileged account, an attacker can exploit the vulnerability and execute code under those same permissions,”. He continued,”A fully patched Windows 10 box lacking the 7-Zip fixes would not help you“.
The Talos security team researcher had found the cause of the problem was broken input validation as a result of bad coding in a patched v16 of the tool. As a result, the hacker would obtain the same access that a logged-on user would have. He went on to explain that the result of the corrupt coding would be an exploitable buffer overflow: “An exploitable heap overflow vulnerability exists in the Archive::NHfs::CHandler::ExtractZlibFile method functionality of 7-Zip‘.
As long ago as 2005, security expert Igor Pavlov tested 7-Zip and detected similar flaws (a ‘stack-based buffer over-flow’). He successfully exploited this to gain Admin level. He rated the vulnerability as 9.3/10 and the ease of remote access as medium difficulty. In 2007, he tested the tool again and only attained partial control, though this vulnerability was also a heap overflow. This demonstrates that this type of 7-Zip vulnerability has been identified in the past.
It is not clear if the open-source nature of this coding led to the deliberate insertion of a vulnerability, though if it was an innocent programming error and not detected in trials, this leaves the possibility for the deliberate insertion of flaws for later hacks.
Shultz conclusion to this situation is that it is essential for application security to validate untrusted input data.
And the question that we should ask is: should secure security software incorporate open-source coding?
