Re: mgetty vulnerable
On Fri, 2 May 2003, Wolfgang Sourdeau wrote: > I am not subscribed to debian-security, so please include me in your Cc: > for this discussion. > Likewise. > I have noticed a "fax" user was expected in mgetty-1.1.30 (never played > with 1.1.29). The problem I have with that is that this user is required at > build time (during the make install phase). Another problem is that > Debian does not have such a user, although one used to exist temporarily > for hylafax a couple of years ago. Now, hylafax is using uucp, so is > pppd and every communication server package I know of in Debian. > > The problem here seems to be that mgetty's sendfax was running under > used root. Now, if we use uucp (which I have modified mgetty 1.1.30 for > last week), I don't see where the problem is. I don't see the point in > requesting the creation of a user for one little program nor do I judge > this compromise (using uucp) as a security issue. > > Please correct me if I am wrong though. > http://www.securityfocus.com/bid/7302 lists some more information. I don't think Debian has this vulnerability either, but I haven't checked. Under Credits you can find a Gentoo and Redhat advisory. Are there any group or world readable directory issues as is suggested to me? I'm talking about for durring installation *and* in normal use. > ps: now it seems Debian mgetty's sendfax is broken since 1.1.30, but > this is another issue which will be fixed before next week. > Off topic, but related... I've been having trouble with mgetty and vgetty for years now. I had it almost working they way I wanted, but then it answered the phone and wouldn't hang up... after that vgetty or mgetty couldn't answer the phone, even after reboot... but I haven't looked into this for a long time now and that box might have fs problems now. Drew Daniels
Re: mgetty vulnerable
Hi, I am not subscribed to debian-security, so please include me in your Cc: for this discussion. I have noticed a "fax" user was expected in mgetty-1.1.30 (never played with 1.1.29). The problem I have with that is that this user is required at build time (during the make install phase). Another problem is that Debian does not have such a user, although one used to exist temporarily for hylafax a couple of years ago. Now, hylafax is using uucp, so is pppd and every communication server package I know of in Debian. The problem here seems to be that mgetty's sendfax was running under used root. Now, if we use uucp (which I have modified mgetty 1.1.30 for last week), I don't see where the problem is. I don't see the point in requesting the creation of a user for one little program nor do I judge this compromise (using uucp) as a security issue. Please correct me if I am wrong though. Wolfgang ps: now it seems Debian mgetty's sendfax is broken since 1.1.30, but this is another issue which will be fixed before next week. pgpvZAd2D11WW.pgp Description: PGP signature
Re: mgetty vulnerable?
* Drew Scott Daniels ([EMAIL PROTECTED]) [030502 01:20]: > [...] There is as far as I can see (only) one important security enhancement in the newer mgettys, and this is running the fax-out-scripts not as root. There is no proof that the old mgettys are vulnerable, but it's never a good idea to run anything as root unless absolutly neccessary. Wolfgang and I are just working to get this running on debian testing/unstable (but _this_ update is not trivial, so it's not just an "apply patch" to get it to the woody version). If anyone has the important desire to use this right now, he should take the sources from unstable and recompile (and make the neccassary enhancements). Everyone else should wait for about an week, then there should be a working version. As minor and major bug fixes are more or less the only changes in mgetty, I would recommend the version in unstable as the security update for everyone who needs it. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
mgetty vulnerable?
I don't know whether potato, woody, sarge and sid should have a security
bug filed against them.
According to http://packages.qa.debian.org/m/mgetty.html sid has version
1.1.30-1, sarge has version 1.1.28-5, and woody has version 1.1.27-4.1.
Note that Debian packages contain changes. I have not looked to see if
these changes might fix the issues, but they should be visible in the
http://saens.debian.org/debian/pool/main/m/mgetty/ directory as the
*.diff.gz files.
Note that it looks like potato contains mgetty 1.1.21-3potato1 which is a
version of mgetty that contains a security fix that fixes the "Immunix
reports that mgetty does not create temporary files in a secure manner,
which could lead to a symlink attack." bug. I'd imagine this change would
have been incorporated in later versions.
The changelog for version 1.1.23-3 says:
mgetty (1.1.21-3) stable; urgency=low
* make mgetty-fax's postinst create /var/spool/fax/outgoing/.last_run
to close a potential symlink exploit by members of the fax group
that is otherwise possible until that file is created
-- Philip Hands <[EMAIL PROTECTED]> Thu, 31 Aug 2000 19:05:13 +0100
I can't see a changelog for version 1.1.23-3potato1, so maybe this is the
diff file for that.
http://search.alphanet.ch/cgi-bin/search.cgi?msgid=20021125142338.E12094%40greenie.muc.de&max_results=1&type=long&domain=ml-mgetty
says:
[...]
Security fixes / concept changes:
* it's now possible to run faxrunq/faxrunqd (and thus sendfax) as
non-root user
* fax spool directories are no longer world-writeable, access is done
via a suid helper program (suid to a special user ID, "fax")
* possible buffer overrun when calling cnd-program (if CallerName is
too long)
* $CALLER_ID, $CALLER_NAME and so on are sanitized before passing to shell
(all quote characters and all non-printable characters are replaced by " ")
[...]
Who should upgrade?
* everbody who is using faxspool/faxrunq on a machine that is shared
with other users that are not 100 per cent trustworthy
* vgetty users with V.253 modems
Distribution vendors:
- I strongly urge you to upgrade to 1.1.29 - older versions are NOT safe
if there are malicious users on the system and faxrunq/faxrunqd are in
use.
- The fax queue handling (faxspool, faxq-helper) needs a new user ID
now ("fax") which MUST own the fax queue directories and SHOULD NOT
own anything else. The user ID is configured in the Makefile.
- faxrunq/faxrunqd can run as user "fax", but in that case the user
needs access to the modem devices (via his primary group id).
Watch out for log file access permissions if this is used!
If anything is unclear, *please* talk to me before rolling out updated
packages that might break things in funny ways.
[...]
Please don't mail [EMAIL PROTECTED] until you are reasonably cetain
potato or woody are vulnerable.
Drew Daniels
