Woohoo, I've actually finally added at least some workaround to always reconnect to the db, this should temporarily fix my weblog page being blank besides the caption most of the time ;-).
Okay, I've planned to do various great stuff today. Well, regarding that, nothing came out of it (as usual). Oh well, I've wrote one paragraph for my article. Otherwise, well, I'm not exactly sure what have I been doing, I can remember some more ELinks reviewing, and some IRC idling.
Then, I've noticed that Linux-2.4.24 came out (fixing the mremap() vulnerability), so I had at least some fun for the evening. First, I was hunting for the vulnerability in 2.2 tree, as it was suggested by the advisory. However, when trying to backport the 2.4 fix (not Linus' 2.6 one, which is quite general and potentially having some side-impacts, so I'm afraid to port it to 2.2), I've found that sys_mremap() in 2.2 is missing that concerned code at all.
Basically, (supposedly) the exploit relies on ability to pass newaddr to mremap(), but in 2.2 mremap() doesn't take it yet. So the only alternative to exploit that is to have the new address automatically assigned by mremap() (and the new address would need to be \"dangerous\" one). However, that's impossible because new size of mremap() must be zero for the exploit and in that case, mremap() would always just munmap() it. Possibilities:
- There is something I don't know about.
- The advisory is mistaken and the 2.2 line is NOT vulnerable.
- If it is vulnerable and I'm not even more misleaded, the 2.4 fix is not complete.
Anyway, mremap() looks dirty, maybe some other vulnerabilities will be discovered in it soon, some people say they are on a track of something. Quite possibly nothing will come up from it, though.
And last I was talking with Dave Weinehall, and he said that he'll make 2.0.40-rc7 available later this week (-rc6 is from May 2002) if everything will go well. Great to see 2.0 still maintained.
And I'll be sleeping for only 6 hours again. Screw it.