Summary: | mail-filter/razor-2.72 DoS vulnerabilities | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sascha Lucas <sascha_lucas> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | jpr5+gentoo, kfm, net-mail+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Other | ||
URL: | http://www200.pair.com/mecham/razor.html | ||
Whiteboard: | B3 [glsaupdate] jaervosz | ||
Package list: | Runtime testing required: | --- |
Description
Sascha Lucas
2005-06-22 04:33:36 UTC
Taviso/Ticho please advise. Yeah, segfaults here: Jun 22 14:05:00.977405 check[4248]: [ 2] Razor-Agents v2.72 starting razor-check -d email3.txt Jun 22 14:05:00.981279 check[4248]: [ 8] reading straight RFC822 mail from email3.txt Jun 22 14:05:00.981987 check[4248]: [ 6] read 1 mail Jun 22 14:05:00.982438 check[4248]: [ 8] Client supported_engines: 4 8 Jun 22 14:05:00.983592 check[4248]: [ 8] prep_mail done: mail 1 headers=92, mime0=572, mime1=393, mime2=3478 Jun 22 14:05:00.984140 check[4248]: [ 6] skipping whitelist file (empty?): /var/lib/amavis/.razor/razor-whitelist Jun 22 14:05:00.984587 check[4248]: [ 5] read_file: 1 items read from /var/lib/amavis/.razor/servers.discovery.lst Jun 22 14:05:00.985093 check[4248]: [ 5] read_file: 2 items read from /var/lib/amavis/.razor/servers.nomination.lst Jun 22 14:05:00.985621 check[4248]: [ 5] read_file: 1 items read from /var/lib/amavis/.razor/servers.catalogue.lst Jun 22 14:05:00.986228 check[4248]: [ 9] Assigning defaults to joy.cloudmark.com Jun 22 14:05:00.986592 check[4248]: [ 9] Assigning defaults to folly.cloudmark.com Jun 22 14:05:00.986836 check[4248]: [ 9] Assigning defaults to shock.cloudmark.com Jun 22 14:05:00.987814 check[4248]: [ 5] read_file: 16 items read from /var/lib/amavis/.razor/server.pride.cloudmark.com.conf Jun 22 14:05:00.988476 check[4248]: [ 5] read_file: 16 items read from /var/lib/amavis/.razor/server.pride.cloudmark.com.conf Jun 22 14:05:00.989098 check[4248]: [ 5] read_file: 15 items read from /var/lib/amavis/.razor/server.joy.cloudmark.com.conf Jun 22 14:05:00.989732 check[4248]: [ 5] read_file: 15 items read from /var/lib/amavis/.razor/server.joy.cloudmark.com.conf Jun 22 14:05:00.990367 check[4248]: [ 5] read_file: 15 items read from /var/lib/amavis/.razor/server.folly.cloudmark.com.conf Jun 22 14:05:00.990981 check[4248]: [ 5] read_file: 15 items read from /var/lib/amavis/.razor/server.folly.cloudmark.com.conf Jun 22 14:05:00.991670 check[4248]: [ 5] read_file: 16 items read from /var/lib/amavis/.razor/server.shock.cloudmark.com.conf Jun 22 14:05:00.992279 check[4248]: [ 5] read_file: 16 items read from /var/lib/amavis/.razor/server.shock.cloudmark.com.conf Jun 22 14:05:00.992691 check[4248]: [ 5] 54396 seconds before closest server discovery Jun 22 14:05:00.993017 check[4248]: [ 6] shock.cloudmark.com is a Catalogue Server srl 5084; computed min_cf=6, Server se: C8 Jun 22 14:05:00.993397 check[4248]: [ 8] Computed supported_engines: 4 8 Jun 22 14:05:00.993672 check[4248]: [ 8] Using next closest server shock.cloudmark.com:2703, cached info srl 5084 Jun 22 14:05:00.993921 check[4248]: [ 8] mail 1 Subject: Undelivered Mail Returned to Sender Jun 22 14:05:00.995543 check[4248]: [ 6] preproc: mail 1.0 went from 572 bytes to 535 Jun 22 14:05:00.996081 check[4248]: [ 6] preproc: mail 1.1 went from 393 bytes to 356 Segmentation fault Patch taken from razor-users mailinglist[1] does help, but as the author himself says, there's no telling if this doesn't affect the functionality. It shouldn't, but I guess we should wait for the upstream to confirm this. 1. http://article.gmane.org/gmane.mail.spam.razor.user/3633 Taviso just a segfault or is rce possible? Adding self as one of the maintainers. Could you guys please add jpr5+gentoo@darkridge.com,mail@vipul.net in the future for all bugs against Razor? That way we would be able to address them much more quickly. FYI, this bug has been fixed internally and we are awaiting results from reporters before rolling the next release. We have also updated the test cases shipped with Razor to include the segfault cases and a few other anomalies we discovered in the process. razor-agents 2.74 was just released, fixing this and several other bugs. You can find the latest release on the razor website, http://razor.sf.net/. *** Bug 96917 has been marked as a duplicate of this bug. *** ignore the last post unless you just feel like reading two different bug reports on different issues stupid bot of mine has an issue with reading Summary sorry net-mail, please bump. Ebuild for 2.74 has been committed into portage, thanks, guys. security: I'll mark x86 stable here as soon as you put this bug into stabilization stage, allowing myself some time to have few mails passed through razor, ensuring nothing's obviously broken. Thus, no need to CC x86@. calling arches - please test and mark stable. thanks for bumping so fast. x86 stable I propose that we release this as an update to GLSA 200506-17. However the GLSA is complicated by being combined with SA. sparc stable. The 2.74 ebuild causes a reproducible sandbox violation here: chmod: /usr/share/man/man5/razor-agent.conf.5 unlink: /usr/share/man/man5/razor-agent.conf.5 I noticed this also when I was testing a homebrew ebuild for a release candidate (2.74_RC4 to be precise) and had intended to report this prior to the final release hitting the portage tree; I apologise that I did not manage to do so. The introduction of this issue is related to this item in the release notes: * Fixed installation of man(5) pages by non-root users to local man directories. [Patch #1227162] Here's a link to the patch in question http://tinyurl.com/dub5p. My approach is to change Makefile.PL:60 from: INSTALLMAN5DIR = $(PREFIX)/share/man/man5 to: INSTALLMAN5DIR = $(DESTDIR)/$(PREFIX)/share/man/man5 which completely solved the problem here. Whatever the approach, I would humbly suggest that the ebuild is silently bumped as soon as reasonably possible. Fixed in 2.74 in CVS, thanks. Funny thing is, I was able to merge 2.74 succesfully several times earlier today, and literally nothing has changed on my system since then, yet now the ebuild gave sandbox violations prior to the fix. Re comment 16: Yes indeed. I had it occur with the release candidate then, quite literally as I was writing about it in an email, it stopped happening but only for a while! Very odd. Recalling sparc: the ebuild needed a small change and was silently bumped after you marked it stable (see comments above), you might want to retest. Looks good too, thanks for the headsup. Stable on ppc. Stable on alpha. Stable on amd64. Ready for GLSA vote (note jaervosz's proposal in comment #13 before voting). Yes, as an update to the previous one. jaervosz agrees GLSA 200506-17 UPDATE |