By cormander
With a lot of companies going to digital phone service now, I think that it’s only a matter of time before someone acquires a botnet of phones by hacking the pbx software/firmware. Once done, the hacker would be able to do denial of service attacks against company’s telephone customer support. Just imagine having hacked even just a few thousand phones; just by having them all dial the 1-800 number, go through the menu to speak to a representative, and sit in the wait queue would cause a lot of trouble for businesses.
It wouldn’t hurt the big companies as much as the smaller ones, but it does scale. What if a hacker had a botnet of 35,000 phone numbers? That would create problems for even companies as big as AT&T, Verizon, DirecTV, etc.
By cormander
A little while ago I made a post about RHEL and all those patches to their kernels. Since that post I started thinking about the patches, and started to experiment with the theory of back-porting.
I currently maintain a list of Linux CVE issues and this is where my experiment begun. If you really think about it – that isn’t a whole lot. Sure these are security specific issues, but I know for a fact that this isn’t a complete list of patches to security issues. But just security fixes asside – exactly how many patches that go into later versions could also apply to old ones?
Turns out, a lot. I mean a LOT. “Holy patches batman!” as Tim might say. About 40% of the 2.6.25 tree (including all patches except ones from release candidate 1) apply cleanly to the 2.6.24.7 kernel. A few reference data structures or functions that don’t exist in 2.6.24.7, and thus cause build errors, so those are removed during the build process. No interfaces change (because the bulk of those happen in the release canidate 1’s, which have thousands of patches in themselves, any anything after that is likely to fail to apply).
Anyway, that’s about 1400 patches! Regression tests with the Linux Test Project after it’s built show no problems. I’ve been running it since I first built it – haven’t seen any issues. Who knows how many potential security problems I just fixed?
So, I updated my grsecurity RPM yum repo 2.6.24.7 branch of the grsecurity kernel with these 1400 some odd patches. When the 2.6.26 linux kernel is released as stable, I’ll have a few thousand more to review. Luckily I have the bulk of it scripted.
I’m sure there are some patches that could still apply to the older kernel with a few tweaks – but I currently don’t have to resources to review each one of the 2100 patches manually for this purpose. I’m also quite certain that this kernel won’t build on arches other then x86 – but all you’d have to do to get it to build is determine which patch caused the build error, which is very easy to do, and reverse it. When I get a 64bit machine to play with, I’ll build the kernels for x86_64. Same goes for other arches – testing will happen when I have the hardware available.
And for version control – since this is the linux kernel we’re talking about – I’m using git. Here is the git repository for this project.
By cormander
Here is a table I put together containing links to the National Vulnerability Database about various Common Vulnerabilities and Exposures (CVE) issues in the 2.6 Linux kernel from 2.6.18 and above:
Linux CVE List
I had originally posted it in here, but decided to make a “page” out of it since it’s something that’ll get updated for a long time.
