Re: [despammed] Re: Secure remote syslogging?
You could hardcode the MAC using static arp entries. Also, you could just broadcast on the logger interface (which doesn't require an ARP lookup, it just uses the broadcast MAC). My concerns with this approach (although I like the sound of it) is that it might fsck up your media detection (eg: is the cable plugged in?) which I think some cards do. I'm also pretty sure this doesn't work with 100Mb. Alternatives: (the traditional line printer was already mentioned), any sort of write-only media will do the trick (eg: CD-RW). You might have to flush batches of log entries to the CD for it to work. I'm not sure what min packet size on UDF FS is. There are probably other cool tricks you could employ. Adam On Tue, 2003-04-29 at 06:30, Ed McMan wrote: > Tuesday, April 29, 2003, 8:54:51 AM, Sam Couter (Sam) wrote: > > Sam> Stefan Neufeind <[EMAIL PROTECTED]> wrote: > >> what is the best way to remotely syslog? In > > Sam> Use a dedicated machine. Cut the 'transmit' pair in the CAT5 cable. > Sam> syslog is UDP, which is only one-way, so it doesn't need to transmit. > > Wouldn't the machine still need to transmit some things, namely arp? > > -- > | Eddie J Schwartz <[EMAIL PROTECTED]|m00.net]> | > | AIM: Uncaring Eyes ICQ: 35576339 YHOO: edmcman2 | > | "We Trills have an expression -- at forty, you| > | think you know everything. At four hundred you| > | realize you know nothing." - Dax, Startrek DS9| > -- > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
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
Re: Injectso to help with libc upgrades?
On Thu, 1 May 2003 18:34:17 +1000 Joshua Goodall <[EMAIL PROTECTED]> wrote: > More debianish would be some kind of additional dependency analyser > that would restart afflicated daemons on your behalf. /usr/bin/checkrestart in debian-goodies :) pgpwg3HQTonYM.pgp Description: PGP signature
Re: Injectso to help with libc upgrades?
On Wed, Apr 30, 2003 at 12:07:33PM -0500, Drew Scott Daniels wrote: > http://packetstorm.linuxsecurity.com/filedesc/injectso-0.2.1.tar.html > describes injectso, "a tool that can be used to inject shared libraries > into running processes on Linux (x86/IA32 and Sparc)...". > > Maybe I misunderstand, but might it not be also possible to use this to > inject replacements for shared libraries too? Not reliably. Even if you can replace the code in the process's memory space, what if some data structures have changed and the program already has some objects allocated? There are doubtless other issues as well (what if the old code is still in a cache?). I'm sure you could concoct something that works "almost all" the time, given some restrictions, like no changes to data structures. But I almost guarantee that the security team will say 1) we don't have time to verify the restrictions, and 2) "almost all" isn't good enough. Andrew PS. Your Mail-Followup-To: header should include the list address. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Injectso to help with libc upgrades?
On Wed, Apr 30, 2003 at 12:07:33PM -0500, Drew Scott Daniels wrote: > http://packetstorm.linuxsecurity.com/filedesc/injectso-0.2.1.tar.html > describes injectso, "a tool that can be used to inject shared libraries > into running processes on Linux (x86/IA32 and Sparc)...". > > Maybe I misunderstand, but might it not be also possible to use this to > inject replacements for shared libraries too? Not reliably. Even if you can replace the code in the process's memory space, what if some data structures have changed and the program already has some objects allocated? There are doubtless other issues as well (what if the old code is still in a cache?). I'm sure you could concoct something that works "almost all" the time, given some restrictions, like no changes to data structures. But I almost guarantee that the security team will say 1) we don't have time to verify the restrictions, and 2) "almost all" isn't good enough. Andrew PS. Your Mail-Followup-To: header should include the list address.
Re: Injectso to help with libc upgrades?
On Thu, 1 May 2003 03:07 am, Drew Scott Daniels wrote: > http://packetstorm.linuxsecurity.com/filedesc/injectso-0.2.1.tar.html > describes injectso, "a tool that can be used to inject shared libraries > into running processes on Linux (x86/IA32 and Sparc)...". > > Maybe I misunderstand, but might it not be also possible to use this to > inject replacements for shared libraries too? I don't think I'd want to leave such a tool lying around on my production servers :} More debianish would be some kind of additional dependency analyser that would restart afflicated daemons on your behalf. J pgp2zUVeXS32a.pgp Description: signature
