The story of the three core vulnerabilities
Recently, Trustwave, an information security firm, published a report announcement criticizing how the Linux community handles vulnerabilities. It says: “Software developers vary greatly in their ability to respond and address zero-day vulnerabilities. This study shows that Linux developers have the worst response time: an average of almost three years from the moment of vulnerability detection to the release of the patch. ” No matter how satisfied you are with the security updates in Linux, three years is much more than we usually expect. Your obedient servant decided to investigate the situation, concentrating on two vulnerabilities that were included in the Trustwave report and one that was not there.
At the time of this writing, the full Trustwave report was not yet available (it can now be downloaded here . - Note. Per. ), So a detailed study of the statements submitted is not possible. But, judging by this article on ZDNet , the average response time was calculated for these two zero-day vulnerabilities:
The problem with the ext4 file system was reported by RN Sastry on October 1, 2009, which conducted fuzz testing of the file system (a type of testing in which the search for errors is performed using random input data. - Note ). The error message also included a file system image that triggers a bug, which is essentially an “exploit” for this vulnerability, which allowed Trustwave to call it a zero-day vulnerability. And, since the problem caused only kernel oops (a system error, after which the kernel panic often happened), and also required cooperation from the victim (mounting the file system prepared by the attacker), the ext4 developers did not consider it necessary to drop everything and immediately eliminate the vulnerability. Ted Ts'o recorded a correction at the end of November. SUSE was the first to publish an update fixing a vulnerability, it happened on January 17, 2010. Red Hat did not release the update until the end of March, almost five months from the moment the information about the vulnerability appeared, and Mandriva waited until February 2011.
')
It can be argued that everything did not happen quickly, even for a bug with extremely low priority, but where did these “three years” come from? They appeared because the fix did not work properly on the x86 architecture. Xi Wang reported that the problem still exists, on December 26, 2011, and sent an intelligent correction on January 9, 2012. This issue was assigned a new CVE number ( CVE-2012-2100 ), and the fix was promptly infused into the mainline. The maintainers were not particularly agile, however, Debian released an update in March, Ubuntu in May, and Red Hat waited until mid-November. It took about eleven months after the discovery of the vulnerability to deliver the patch to the users. Since the discovery of the problem until the release of the Red Hat update, which finally solved the problem, indeed, more than three years have passed.
The story of HFS / HFS + is very similar. The first patch that resolves the HFS buffer overflow problem was published by Amerigo Wang in early December 2009. The fix was committed by Linus on December 15, and the Red Hat maintainers began distributing the update on January 19, 2010. Some maintainers were even slower, but this vulnerability was also recognized as difficult to exploit and was considered a low priority.
The problem is that the kernel supports another (more recent) file system called HFS +. This is a standalone implementation, containing a fair amount of code copied from the original HFS implementation, just like ext4 was started by copying ext3. The danger of such duplication of code is well known: the developer corrects the problem in one copy, without even suspecting that the same problem may be in the other. Naturally, this happened here. The HFS + implementation had the same buffer overflow vulnerability, but no one thought about it until Timo Warns caught the attention of several kernel developers at the end of April 2012. Greg Kroah-Hartman published the changes on May 4, and the issue went public several days after that. And again, a new CVE number was assigned ( CVE-2012-2319 ), and again the maintainers missed with corrections. OpenSUSE released an update in June, while Red Hat waited until October, five months after the problem became known. From the time of discovery until the publication of the fix in Red Hat, a little less than three years have passed.
But you can look at this problem from different angles. On the one hand, it is obvious that Trustwave specifically chose these vulnerabilities and then interpreted them to show the maximum possible repair time. But none of the stories describe the zero-day vulnerability that would remain open for three years; most of the time it was assumed that the problem was solved. This is doubly true for HFS +, a vulnerability in which was not even known until May 2012. And, given the nature of these vulnerabilities, it is highly unlikely that black hats jealously concealed them all this time, and most likely no system was compromised with their use. Trustwave’s claims, if based on these two vulnerabilities, are dubious and exaggerated at best.
On the other hand, even low-priority vulnerabilities requiring actions by the victim must be corrected correctly and if possible quickly. But, in fact, not everything is so simple with what happened with these vulnerabilities. The response to the ext4 problem was quite fast, especially considering the nature of the problem, but the fact that the problem was still relevant on the x86 architecture shows that at least testing was at least unsatisfactory. In the case of HFS / HFS +, who can even blame someone for not seeing, is there a duplicate bug in some other place? On the background of the fact that the HFS and HFS + file systems are almost not used and, one might say, are not supported, the claims do not hold water. However, attackers are not limited to well-supported code. And, in both cases, the maintainers did not bother to deliver fixes to their users. It would be possible to work better.
Probably the slowness shown above is a natural response to vulnerabilities that nobody really cares about. If they were a more serious reaction, undoubtedly, would be much better. And as is usually the case, at the time of writing the article (article published February 19, 2013. - Approx. Lane. ), There is an open vulnerability, so that we can observe how well we can react. And the answer is not encouraging.
On January 20, the discussion from the private mailing list on kernel security became public in connection with the publication of a patch written by Oleg Nesterov. It was demonstrated that the implementation of the
February 15 vulnerability was discovered and published, and with a very high-quality code for the exploit, for those who do not want to write their own. Most victims are unlikely to apply a patch to the core to make it easier to realize the race condition, and the exploit also needs to work in real time in order to win the race more reliably. But even without a patch and real-time work, a patient enough attacker can get a result. Here’s how the Solar Designer vulnerability responded :
Actually, this should not be a zero-day vulnerability, since the public discussion of the correction has already been about a month, and the private one has been going on for some time before that. But at the time of writing, no distribution has yet released updates for this problem. Which leads us to some obvious questions. Again we quote Solar Designer:
This statement suggests that similar problems are possible in the future. In the meantime, users and system administrators around the world need to worry about whether their systems are vulnerable and who can exploit these vulnerabilities.
And again: we can work better. From the very beginning it was known that this was a serious problem; One of the developers who reported on it (Salman Qazi from Google) also attached an exploit to show how serious the situation is. Maintainers knew about the problem and had enough time to respond to it, but still did not respond in a timely manner. The problem with
Note from the translator:
The fix in Debian was released on February 25, in Red Hat - February 26, in Ubuntu - February 21, in OpenSUSE - February 25.
Three years?
At the time of this writing, the full Trustwave report was not yet available (it can now be downloaded here . - Note. Per. ), So a detailed study of the statements submitted is not possible. But, judging by this article on ZDNet , the average response time was calculated for these two zero-day vulnerabilities:
- CVE-2009-4307 : division by zero error in ext4 file system code. To exploit this vulnerability, it is necessary for the user to mount a specially prepared ext4 file system image.
- CVE-2009-4020 : HFS + file system buffer overflow; operated again by mounting a specially prepared image of the file system on the target system.
The problem with the ext4 file system was reported by RN Sastry on October 1, 2009, which conducted fuzz testing of the file system (a type of testing in which the search for errors is performed using random input data. - Note ). The error message also included a file system image that triggers a bug, which is essentially an “exploit” for this vulnerability, which allowed Trustwave to call it a zero-day vulnerability. And, since the problem caused only kernel oops (a system error, after which the kernel panic often happened), and also required cooperation from the victim (mounting the file system prepared by the attacker), the ext4 developers did not consider it necessary to drop everything and immediately eliminate the vulnerability. Ted Ts'o recorded a correction at the end of November. SUSE was the first to publish an update fixing a vulnerability, it happened on January 17, 2010. Red Hat did not release the update until the end of March, almost five months from the moment the information about the vulnerability appeared, and Mandriva waited until February 2011.
')
It can be argued that everything did not happen quickly, even for a bug with extremely low priority, but where did these “three years” come from? They appeared because the fix did not work properly on the x86 architecture. Xi Wang reported that the problem still exists, on December 26, 2011, and sent an intelligent correction on January 9, 2012. This issue was assigned a new CVE number ( CVE-2012-2100 ), and the fix was promptly infused into the mainline. The maintainers were not particularly agile, however, Debian released an update in March, Ubuntu in May, and Red Hat waited until mid-November. It took about eleven months after the discovery of the vulnerability to deliver the patch to the users. Since the discovery of the problem until the release of the Red Hat update, which finally solved the problem, indeed, more than three years have passed.
The story of HFS / HFS + is very similar. The first patch that resolves the HFS buffer overflow problem was published by Amerigo Wang in early December 2009. The fix was committed by Linus on December 15, and the Red Hat maintainers began distributing the update on January 19, 2010. Some maintainers were even slower, but this vulnerability was also recognized as difficult to exploit and was considered a low priority.
The problem is that the kernel supports another (more recent) file system called HFS +. This is a standalone implementation, containing a fair amount of code copied from the original HFS implementation, just like ext4 was started by copying ext3. The danger of such duplication of code is well known: the developer corrects the problem in one copy, without even suspecting that the same problem may be in the other. Naturally, this happened here. The HFS + implementation had the same buffer overflow vulnerability, but no one thought about it until Timo Warns caught the attention of several kernel developers at the end of April 2012. Greg Kroah-Hartman published the changes on May 4, and the issue went public several days after that. And again, a new CVE number was assigned ( CVE-2012-2319 ), and again the maintainers missed with corrections. OpenSUSE released an update in June, while Red Hat waited until October, five months after the problem became known. From the time of discovery until the publication of the fix in Red Hat, a little less than three years have passed.
But you can look at this problem from different angles. On the one hand, it is obvious that Trustwave specifically chose these vulnerabilities and then interpreted them to show the maximum possible repair time. But none of the stories describe the zero-day vulnerability that would remain open for three years; most of the time it was assumed that the problem was solved. This is doubly true for HFS +, a vulnerability in which was not even known until May 2012. And, given the nature of these vulnerabilities, it is highly unlikely that black hats jealously concealed them all this time, and most likely no system was compromised with their use. Trustwave’s claims, if based on these two vulnerabilities, are dubious and exaggerated at best.
On the other hand, even low-priority vulnerabilities requiring actions by the victim must be corrected correctly and if possible quickly. But, in fact, not everything is so simple with what happened with these vulnerabilities. The response to the ext4 problem was quite fast, especially considering the nature of the problem, but the fact that the problem was still relevant on the x86 architecture shows that at least testing was at least unsatisfactory. In the case of HFS / HFS +, who can even blame someone for not seeing, is there a duplicate bug in some other place? On the background of the fact that the HFS and HFS + file systems are almost not used and, one might say, are not supported, the claims do not hold water. However, attackers are not limited to well-supported code. And, in both cases, the maintainers did not bother to deliver fixes to their users. It would be possible to work better.
Meanwhile in 2013
Probably the slowness shown above is a natural response to vulnerabilities that nobody really cares about. If they were a more serious reaction, undoubtedly, would be much better. And as is usually the case, at the time of writing the article (article published February 19, 2013. - Approx. Lane. ), There is an open vulnerability, so that we can observe how well we can react. And the answer is not encouraging.
On January 20, the discussion from the private mailing list on kernel security became public in connection with the publication of a patch written by Oleg Nesterov. It was demonstrated that the implementation of the
ptrace() system call in the Linux kernel contains race conditions: the registers of the process being traced can be modified so that the kernel restores the contents of the stack of this process to an arbitrary location. Ultimately, this leads to the possibility of executing arbitrary code in kernel mode. The attack is carried out locally, so the attacker must launch an exploit on the target system. But having the opportunity to run such a program, it can use the full set of root privileges. These kinds of vulnerabilities require immediate attention. Any system with a similar vulnerability is actually handed over to the delight of any (including untrusted) user with an account, or any hacker who can compromise a network service and run an arbitrary program.February 15 vulnerability was discovered and published, and with a very high-quality code for the exploit, for those who do not want to write their own. Most victims are unlikely to apply a patch to the core to make it easier to realize the race condition, and the exploit also needs to work in real time in order to win the race more reliably. But even without a patch and real-time work, a patient enough attacker can get a result. Here’s how the Solar Designer vulnerability responded :
I have not had time to carefully look at all this, but at first glance, this is the worst vulnerability in a few years. For mainteners of distribution kernels (other than the main branch, which was patched almost a month ago), this is 0-day.
Actually, this should not be a zero-day vulnerability, since the public discussion of the correction has already been about a month, and the private one has been going on for some time before that. But at the time of writing, no distribution has yet released updates for this problem. Which leads us to some obvious questions. Again we quote Solar Designer:
The commits of Oleg Nesterov from Red Hat hit the main branch in January. Why in Red Hat the problem was not (?) Handled with all seriousness, well, or in the end, the information was not published, which of their cores are affected by this vulnerability at the moment.
This statement suggests that similar problems are possible in the future. In the meantime, users and system administrators around the world need to worry about whether their systems are vulnerable and who can exploit these vulnerabilities.
And again: we can work better. From the very beginning it was known that this was a serious problem; One of the developers who reported on it (Salman Qazi from Google) also attached an exploit to show how serious the situation is. Maintainers knew about the problem and had enough time to respond to it, but still did not respond in a timely manner. The problem with
ptrace() solved in less than 3 years, but there is nothing to be proud of. Users can not be left to fend for the whole month (if not more), since the mainteyner learned about this problem.Note from the translator:
The fix in Debian was released on February 25, in Red Hat - February 26, in Ubuntu - February 21, in OpenSUSE - February 25.
Source: https://habr.com/ru/post/217759/
All Articles