Re: murphy in sbl.spamhaus.org
On Friday 26 November 2004 03.34, Stephen Frost wrote: * Adrian 'Dagurashibanipal' von Bidder ([EMAIL PROTECTED]) wrote: plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. Things which increase the load on the remote mail servers are *bad*. That would include responding with temporary errors unnecessairly and adding unnecessary delays in communication. pipelining by itself isn't necessairly terrible- adding things like 2 minute delays is bad though. I'm happy to queue my outgoing email if the remote end uses greylisting, as I expect the remote site to queue my incoming mail with my greylisting. Add to the the fact that amongst the mail senders big enough so that the queue size matters are probably many of those ISPs with badly policed (DSL/cable) network, operating the spam zombies which cause me to use greylisting in the first place... About pipelining: what postfix does is enforce proper use of pipelining: the sender may only start pipelining requests when it has actually seen that postfix does support pipelining. Regular mail servers never notice this, but some stupid spammers just push the request out without waiting for responses at all - these are rejected. -- vbi -- TODO: apt-get install signify pgpfp7vTpvIYg.pgp Description: PGP signature
Re: murphy in sbl.spamhaus.org
On Thursday 25 November 2004 10.50, Lupe Christoph wrote: Now it is in Spamcop's list: http://www.spamcop.net/w3m?action=checkblockip=146.82.138.6 spamcop does explicitly not recommend using their RBL for blocking - they know why. That's the downside of a fully automated system. Every mailserver with more than a few 1000 users are bound to end up on spamcop again and again, either because spamcop's header parsing is broken (it is, sometimes), or because some users are reporting 'spam' that isn't. rantThis is the fourth RBL I had to remove because all those SFBs are too Stoopid(tm) to whitelist important mail servers./rant Happy with - sbl-xbl.spamhaus.org - list.dsbl.org - relays.ordb.org and until recently SPEWS (dropped it because it didn't catch much that wasn't caught by the others already.) I used to use the country based blackholes list for cn and tw for a while, but I don't see the need anymore. plug And, of course, postgrey as the very first line of defense. /plug Coupled with the usual checking on HELO (blocking 'localhost' HELOs and my own IP does wonders!), SMTP protocol conformance (pipelining), sender (envelope) address checking. -- vbi -- TODO: apt-get install signify pgpv05HFyKDlf.pgp Description: PGP signature
Re: [fx.net.nz #457] AutoReply: [SECURITY] [DSA 574-1] New cabextract packages fix unintended directory traversal
If you gate debian security announcement into your ticketing system, please don't send auto-acks to debian-security. thanks -- vbi On Thursday 28 October 2004 09.19, you wrote: Greetings, Please do not reply to this automatically generated email. Thank you for your message to fx.net.nz. The ticket number for this matter is 457. You can automatically trace this matter at crm.fx.net.nz using the ticket number. If you are checking via email, then please include the string: [fx.net.nz #457]in the subject line Also please quote this number in any correspondence. Thank you, The [EMAIL PROTECTED] team. - - - Debian Security Advisory DSA 574-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze October 28th, 2004 http://www.debian.org/security/faq - - Package: cabextract Vulnerability : missing directory sanitising Problem-Type : remote Debian-specific: no CVE ID : CAN-2004-0916 Debian Bug : 277522 The upstream developers discovered a problem in cabextract, a tool to extract cabinet files. The program was able to overwrite files in upper directories. This could lead an attacker to overwrite arbitrary files. For the stable distribution (woody) this problem has been fixed in version 0.2-2b. For the unstable distribution (sid) this problem has been fixed in version 1.1-1. We recommend that you upgrade your cabextract package. Upgrade Instructions wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody Source archives: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b.dsc Size/MD5 checksum: 568 72c81704917abe1f37ae4694392c97e3 http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b.diff.gz Size/MD5 checksum: 2314 d31e74e1186f00a60dc944bec28829f9 http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2. orig.tar.gz Size/MD5 checksum:66136 8f59514ec67cfb43658c57c67c864b74 Alpha architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_alpha.deb Size/MD5 checksum:20344 2eba57f87ea2348e3e0322eb5d7ce3a5 ARM architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_arm.deb Size/MD5 checksum:16514 0c1b72dfef4454c9a4140d4728b6d56d Intel IA-32 architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_i386.deb Size/MD5 checksum:15054 f0b5a915d31a51dbad5df5163c326204 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_ia64.deb Size/MD5 checksum:23934 7a180cb2c7321533839d88edfde0664e HP Precision architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_hppa.deb Size/MD5 checksum:17784 50e507a1108c883a550f6b14b01238be Motorola 680x0 architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_m68k.deb Size/MD5 checksum:15034 e576be7c48a6217bc3d04f850b622ea9 Big endian MIPS architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_mips.deb Size/MD5 checksum:17948 427396df5074b07059f35d1603512423 Little endian MIPS architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_mipsel.deb Size/MD5 checksum:17884 de2d86ebeb9fdcaf58f99e403ca4ba86 PowerPC architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_powerpc.deb Size/MD5 checksum:16572 f087bc23f1a5ff782ad4a15563482af0 IBM S/390 architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_s390.deb Size/MD5 checksum:16658 44e78328ade15ef1b71fe5fec2738bc7 Sun Sparc architecture: http://security.debian.org/pool/updates/main/c/cabextract/cabextract_0.2- 2b_sparc.deb Size/MD5 checksum:18692 ad98229293a9a753db5d371cab657d06 These files will probably be moved into the stable distribution on its next update. - For apt-get: deb
Re: [OT] Collective memory query
On Tuesday 28 September 2004 15.49, Bartosz Fenski aka fEnIo wrote: On Mon, Sep 27, 2004 at 06:38:03PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: for foo in `find . -name something` Note that $ for foo in `command outputting a list of filenames` should *always* be replaced by $ said command | while read foo; do ... [...] So what is the magic barrier when this should stop working? I'm just curious. Hmm. I can't comment on that specifically, for current versions of some shells. I know I have seen 'command line too long' messages in the past when using `find ...` constructs, and I bet that on busybox based resscue disks and other restricted shells this topic will still be relevant. In any case, using the while loop will pipeline the operations so you get full benefit from multitasking. greetings -- vbi -- Beware of the FUD - know your enemies. This week * The Alexis de Toqueville Institue * http://fortytwo.ch/opinion/ pgpmXk5scEIfr.pgp Description: PGP signature
Re: [OT] Collective memory query
On Monday 27 September 2004 16.28, Mason Loring Bliss wrote: for foo in `find . -name something` Note that $ for foo in `command outputting a list of filenames` should *always* be replaced by $ said command | while read foo; do ... (Or, for trivial cases, xargs) because the for loop will not work with more than a few hundred files. greetings -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/ pgpsDpOWzKgsc.pgp Description: PGP signature
Re: Spyware / Adware
On Wednesday 01 September 2004 12.06, Duncan Simpson wrote: BTW binaries are pretty portable across linux systems. I had some libc 4.x (a.out) binaries on my older box from SLS 1.03 (kernel 0.99pl13) at least until the 1.2.x kernels. I don't know exactly why you mention this here, but as the only other mention of binaries and portability in this thread was, irrc, mine... My point was not about standardized APIs and ABIs, but about binary exploits. These are as a rule very brittle and depend on precise library and compiler version and on compiler options: most (all?) buffer overruns need at least to know some parts of the stack layout to work - and register allocations, and with it, the stack layout, is bound to change wildly between different compiler versions even if the system ABI/APIs do not change. greetings -- vbi -- The finest eloquence is that which gets things done. pgpdNgvIrXm6p.pgp Description: PGP signature
Re: Spyware / Adware
On Tuesday 31 August 2004 13.30, Volker Tanger wrote: [spyware/adware/trojans/...:] Yes and no. When surfing as normal user *ware programs cannot install themselves as system services or overwrite programs simply as you/they do not have the (file) permissions to do so. Technically, for most purposes, malware installing itself into an unprivileged user account and automatically starting itself through ~/.bashrc or whatever is entirely possible, especially since most malware these days seems to be used only as a base for DDOS attacks (including sending spam), so no special privileges are necessary here. (And KDE and Gnome are currently catching up nicely in the number of little useful (?) daemons that are started on a desktop machine.) Windows currently having 90% of the desktop market protects Linux and other systems currently: malware could not propagate fast enough. Also, most email clients don't offer to execute arbitrary email attachments. OTOH, I wouldn't trust the Javascript implementations in the Linux browsers any more than I trust the Javascript implementation of IE. Another thing that protects Linux systems: heterogenity. Binary exploits usually only work properly when a program is compiled and linked with specific compiler and library versions -- with different versions, all you get is a crash (which does no real harm in most cases). I think there are far more different Linux versions out there than there are Windows versions, so I *think* that even with Linux becoming a more attractive target, you'll never get a single malware spreading with a speed comparable to what's happening in Windows today. greets -- vbi -- According to my calculations the problem doesn't exist. pgp0P0nfzQmj6.pgp Description: PGP signature
Re: advice needed on how to proceed
On Friday 30 July 2004 23.41, David A.Ulevitch wrote: I see no harm in leaving the bug open or if you do mark it as won't fix I would indicate that it is because you aren't the person to fix it and/or can't fix it but don't say there is no security vulnerability. I think this should be the 'help' tag instead of 'wontfix', then? greetings -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/ pgp6ZxebXukSy.pgp Description: signature
Re: [mailinglists] Re: new tool - apt-method-https
On Saturday 17 July 2004 16.35, hanasaki wrote: Anyone verify this is for real and not social engineering and a trojen? I'm sure everybody would be happy if you did a code review and posted it here (free software/open source is wonderful, isn't it?) Unfounded speculations like this are certainly not the way to go - if you don't trust the software, don't use it. cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/ pgpakjiiuIOZz.pgp Description: signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
Could you guys please stop sending cc:s my way? Debian list policy suggests not to do this, and I never requested cc:s. Thank you. -- vbi On Saturday 10 July 2004 17.37, Florian Weimer wrote: * Jeroen van Wolffelaar: Actually, it's rather time-consuming to determine if a security vulnerability has been published. You have to discover the ... -- Today is Boomtime, the 46th day of Confusion in the YOLD 3170 pgpH2o6JYHWJw.pgp Description: signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Wednesday 07 July 2004 18.28, Matt Zimmerman wrote: On Wed, Jul 07, 2004 at 01:17:01PM +0200, Jeroen van Wolffelaar wrote: On Wed, Jul 07, 2004 at 02:49:54AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Why does the security team have to do this? Anybody can do it. Not without spending lots of time crawling through security lists, CAN/CVE's, bugtraq, verifying whether debian has the offending version, etc. How do you think the security team does it? We do not have a magic filter which shows us only issues which affect Debian stable; this is all done by hand. I think Jeroen is thinking about security problems the security team already knows about but has not yet had time to handle (and which have already been made public somewhere else.) Stupid if somebody has to search the sources *again* if the security team already has the information. greetings -- vbi -- featured product: SpamAssassin - http://spamassassin.org pgpXqgOaGf4BX.pgp Description: signature
cvs server under attack
Hi, I've seen repeated login failures on my cvs pserver - is there any new security issue? I have current testing, and from the changelog it seems that this contains all the fixes that current stable + security provides, so it would seem safe. Also, I only see login failures in the log, nothing suspicious, so I'm inclined to believe that it's just an exploit out there for the script kiddies to play around with. Still, the bad feeling persists... cheers -- vbi -- Quando un bancario muore viene seppellito in una cassa costosa o in una cassa di risparmio? -- Da it.hobby.umorismo pgp4Hl3mUmVBu.pgp Description: signature
cvs server under attack
Hi, I've seen repeated login failures on my cvs pserver - is there any new security issue? I have current testing, and from the changelog it seems that this contains all the fixes that current stable + security provides, so it would seem safe. Also, I only see login failures in the log, nothing suspicious, so I'm inclined to believe that it's just an exploit out there for the script kiddies to play around with. Still, the bad feeling persists... cheers -- vbi -- Quando un bancario muore viene seppellito in una cassa costosa o in una cassa di risparmio? -- Da it.hobby.umorismo pgpBU4oZcdX1U.pgp Description: signature
Re: rbl's status?
On Sunday 13 June 2004 18.01, Dale Amon wrote:
What are the recommended rbl's these days?
Just one opinion more:
(ok, this is postfix syntax. But let's not start this war here :-)
reject_rbl_client cbl.abuseat.org,
reject_rbl_client list.dsbl.org,
these are very good and catch most.
reject_rbl_client cn-kr.blackholes.us,
And 70% of what is not caught above hangs here. Obviously, if you have
regular emaul traffic with them, you shouldn't do this...
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl.spamhaus.org,
Catches not much these days, especially not much that is not already in
abuseat. But still 10-20 emails per week.
reject_rbl_client spews.blackholes.us,
SPEWS is very controversial. It blocks spammers and spam-supporters, the
latter may include big IP ranges from ISPs that do not react to
complaints. Also, SPEWS is not really transparent. They have 'case
files', but IMHO they are hard to read and not really clear. I've not
had false positives that I know of because of this, but still, I
wouldn't use it in a business server.
Additionally, I used to use {comcast,rr}.blackholes.us, but abuseat
contains most of the spamzombies already, so I dropped them. Similarly,
reject_rhsbl_client spamdomains.blackholes.easynet.nl,
reject_rhsbl_sender spamdomains.blackholes.easynet.nl,
reject_rhsbl_client porn.rhs.mailpolice.com,
reject_rhsbl_sender porn.rhs.mailpolice.com,
reject_rhsbl_client bulk.rhs.mailpolice.com,
reject_rhsbl_sender bulk.rhs.mailpolice.com,
and
warn_if_reject reject_rbl_client bogons.cymru.com,
warn_if_reject reject_rbl_client spam.dnsrbl.net,
warn_if_reject reject_rbl_client es.blackholes.easynet.nl,
were dropped after they found nothing the ones I *do* use still didn't
already find. I've stopped using the latter three quite some time ago,
so maybe they don't work anymore now.
Also you may want to look at the rfc-ignorant.org ones, but reading
nanae I got the impression that they are more trouble than they're
worth.
In any case, I recommend that you thoroughly read information about the
blacklists you use, and that you follow some news source about spam
fighting, so that important news like some blacklist going bellyup and
blacklisting the world will not creep up on you from behind. One source
is nanae, which is unfortunately quite high volume and consists 70% of
flamewars. But I've not found a better source for information - just
ignore the trolls. (Honestly, when you follow nanae, the little
arguments on the debian lists are really soothing to the mind in their
mind-boggingly rationality and calm and to the point style of
discussion.)
cheers
-- vbi
--
featured link: http://fortytwo.ch/gpg/intro
pgpIEVQHpeyHW.pgp
Description: signature
Re: rbl's status?
On Sunday 13 June 2004 18.01, Dale Amon wrote:
What are the recommended rbl's these days?
Just one opinion more:
(ok, this is postfix syntax. But let's not start this war here :-)
reject_rbl_client cbl.abuseat.org,
reject_rbl_client list.dsbl.org,
these are very good and catch most.
reject_rbl_client cn-kr.blackholes.us,
And 70% of what is not caught above hangs here. Obviously, if you have
regular emaul traffic with them, you shouldn't do this...
reject_rbl_client relays.ordb.org,
reject_rbl_client sbl.spamhaus.org,
Catches not much these days, especially not much that is not already in
abuseat. But still 10-20 emails per week.
reject_rbl_client spews.blackholes.us,
SPEWS is very controversial. It blocks spammers and spam-supporters, the
latter may include big IP ranges from ISPs that do not react to
complaints. Also, SPEWS is not really transparent. They have 'case
files', but IMHO they are hard to read and not really clear. I've not
had false positives that I know of because of this, but still, I
wouldn't use it in a business server.
Additionally, I used to use {comcast,rr}.blackholes.us, but abuseat
contains most of the spamzombies already, so I dropped them. Similarly,
reject_rhsbl_client spamdomains.blackholes.easynet.nl,
reject_rhsbl_sender spamdomains.blackholes.easynet.nl,
reject_rhsbl_client porn.rhs.mailpolice.com,
reject_rhsbl_sender porn.rhs.mailpolice.com,
reject_rhsbl_client bulk.rhs.mailpolice.com,
reject_rhsbl_sender bulk.rhs.mailpolice.com,
and
warn_if_reject reject_rbl_client bogons.cymru.com,
warn_if_reject reject_rbl_client spam.dnsrbl.net,
warn_if_reject reject_rbl_client es.blackholes.easynet.nl,
were dropped after they found nothing the ones I *do* use still didn't
already find. I've stopped using the latter three quite some time ago,
so maybe they don't work anymore now.
Also you may want to look at the rfc-ignorant.org ones, but reading
nanae I got the impression that they are more trouble than they're
worth.
In any case, I recommend that you thoroughly read information about the
blacklists you use, and that you follow some news source about spam
fighting, so that important news like some blacklist going bellyup and
blacklisting the world will not creep up on you from behind. One source
is nanae, which is unfortunately quite high volume and consists 70% of
flamewars. But I've not found a better source for information - just
ignore the trolls. (Honestly, when you follow nanae, the little
arguments on the debian lists are really soothing to the mind in their
mind-boggingly rationality and calm and to the point style of
discussion.)
cheers
-- vbi
--
featured link: http://fortytwo.ch/gpg/intro
pgpADeU9SSqkC.pgp
Description: signature
cvs exploits - when triggerable?
Hi all! http://security.e-matters.de/advisories/092004.html In most cases, this is a bit vague on when an attacker can trigger the bugs. pserver without authentication? pserver anonymous access? pserver readonly access? pserver commit access? ssh/local access? In a few cases, it is mentioned that CVSROOT commit access is needed, so these are no problem. But the others? greetings -- vbi [please don't cc: me] -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro) pgpHC8MMNbMxy.pgp Description: signature
cvs exploits - when triggerable?
Hi all! http://security.e-matters.de/advisories/092004.html In most cases, this is a bit vague on when an attacker can trigger the bugs. pserver without authentication? pserver anonymous access? pserver readonly access? pserver commit access? ssh/local access? In a few cases, it is mentioned that CVSROOT commit access is needed, so these are no problem. But the others? greetings -- vbi [please don't cc: me] -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro) pgp5hczNYziKz.pgp Description: signature
Re: SSH, PubkeyAuthentication and UsePam - security problem or RTFM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 20 April 2004 15.40, Stefan Fritsch wrote: Hi! Am Dienstag, 20. April 2004 15:27 schrieb Adrian 'Dagurashibanipal' von Bidder: So, to rephrase the question, is there a way to have PAM set up my session (specifically, pam_env) without allowing users to log in with their password? I think you can do this by removing a line in /etc/pam.d/ssh . I think auth required pam_unix.so should be the one. Read the docs or maybe someone else remembers wether this is correct... Works for me, great! cheers - -- vbi - -- featured product: PostgreSQL - http://postgresql.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkCHqFtgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6qYkAn3zLbHd9FnmhsBG/FSafUs9l NauCAJ0Z5RF/WMODN4Uo6SZDRSQGfFZMvQ== =CoEx -END PGP SIGNATURE-
SSH, PubkeyAuthentication and UsePam - security problem or RTFM?
[Matthew, Colin - I suspect you're on debian-security anyway. If so, no need to reply off-list; I just wanted to make sure you see this, since I considered filing a bug about this.] Hi, Package: ssh Version: 1:3.8p1-3 Tags: bug-not-filed I have a cople of issues with UsePam in ssh. First, it seems to always enable PasswordAuthentication. All my systems have 'PasswordAuthentication no' and 'PubkeyAuthentication yes', so I was very surprised when I was prompted for a password trying to login to one of the systems, to an account with an outdated authorized_keys file. Investigation showed that 'UsePam yes' is causing this behaviour (i.e. 'UsePam no' turns off PasswordAuthentication). IMHO this is quite a bug, as I rely on the fact that 'PasswordAuthentication no' disables password authentication. But of course, having to disable pam has a big drawback: the pam_env module is not loaded anymore :-( I can see how PubkeyAuthentication and pam could conflict, but is there no way to work around this? And, for the short term, what is the 'official' suggested way to read /etc/environment? IIRC it is not really recommended to just source it in /etc/profile (all users have $SHELL == bash.) Preferably in a way that does not blindly read /etc/environment when pam_env *was* loaded. greetings -- vbi -- Lieber schlau in die Bluse schau'n, als dumm in die Wäsche gucken! pgp0.pgp Description: signature
SSH, PubkeyAuthentication and UsePam - security problem or RTFM?
[Matthew, Colin - I suspect you're on debian-security anyway. If so, no need to reply off-list; I just wanted to make sure you see this, since I considered filing a bug about this.] Hi, Package: ssh Version: 1:3.8p1-3 Tags: bug-not-filed I have a cople of issues with UsePam in ssh. First, it seems to always enable PasswordAuthentication. All my systems have 'PasswordAuthentication no' and 'PubkeyAuthentication yes', so I was very surprised when I was prompted for a password trying to login to one of the systems, to an account with an outdated authorized_keys file. Investigation showed that 'UsePam yes' is causing this behaviour (i.e. 'UsePam no' turns off PasswordAuthentication). IMHO this is quite a bug, as I rely on the fact that 'PasswordAuthentication no' disables password authentication. But of course, having to disable pam has a big drawback: the pam_env module is not loaded anymore :-( I can see how PubkeyAuthentication and pam could conflict, but is there no way to work around this? And, for the short term, what is the 'official' suggested way to read /etc/environment? IIRC it is not really recommended to just source it in /etc/profile (all users have $SHELL == bash.) Preferably in a way that does not blindly read /etc/environment when pam_env *was* loaded. greetings -- vbi -- Lieber schlau in die Bluse schau'n, als dumm in die Wäsche gucken! pgpdx6wTBa4T9.pgp Description: signature
Re: SSH, PubkeyAuthentication and UsePam - security problem or RTFM?
On Tuesday 20 April 2004 14.24, Giacomo Mulas wrote: First, it seems to always enable PasswordAuthentication. All my systems have 'PasswordAuthentication no' and 'PubkeyAuthentication yes', so I was very surprised when I was prompted for a password trying to login to one of the systems, to an account with an outdated authorized_keys file. Investigation showed that 'UsePam yes' is causing this behaviour (i.e. 'UsePam no' turns off PasswordAuthentication). you are not seeing PasswordAuthentication, you are seeing keyboard-interactive authentication. They are two distinct things and get enabled/disabled separately. Either way, it allows people to authenticate with their account password instead of an ssh key. Is this distinction documented somewhere? I guess the sshd_config(5) section about UsePAM counts for documentation, but does not help me with my problem. So, to rephrase the question, is there a way to have PAM set up my session (specifically, pam_env) without allowing users to log in with their password? I think it's just annoying to have the session setup twice, once in pam and once in wherever, and have my ssh sessions look different from my local login sessions. The two sets of configuration will certainly diverge over time... cheers -- vbi -- Wir müssen heute nach den Wahrheiten leben, die uns zur Verfügung stehen, dabei aber immer bereit sein, sie morgen Irrtümer zu nennen. -- William James pgppiaJUtpwqv.pgp Description: signature
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 16 April 2004 08.20, David R wrote: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). You can just hold down the shift or control key when booting, this gets you the lilo prompt in any case (I always have prompt disabled, no need to delay the boot in the normal case, and on a desktop booting is a frequent enough occasion to make it worth the effort) - -- vbi - -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB/jYlgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6WVYAn3Cn69vQpDLFfFZyrqRpq6La 5OJJAJwKtXk3jTpHUcwd81IPhJJzSLU8nQ== =34lV -END PGP SIGNATURE-
Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 16 April 2004 08.20, David R wrote: 1) At first, didn't realize I needed to uncomment the word prompt in lilo.conf (though I figured this one out before posting to the group). You can just hold down the shift or control key when booting, this gets you the lilo prompt in any case (I always have prompt disabled, no need to delay the boot in the normal case, and on a desktop booting is a frequent enough occasion to make it worth the effort) - -- vbi - -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB/jYlgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6WVYAn3Cn69vQpDLFfFZyrqRpq6La 5OJJAJwKtXk3jTpHUcwd81IPhJJzSLU8nQ== =34lV -END PGP SIGNATURE-
Re: [DSA 479-2] New Linux 2.4.18 packages fix local root exploit (i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 15 April 2004 11.56, Tim Nicholas wrote: On 04/15/04 20:05, Michelle Konzack wrote: Question: What about the Bootfloppies ? If I recall correctly it is assumed that users will not run on the boot floppy kernels after the initial system installation. They are expected to install a more appropriate kernel after finishing the install. But who tells them? IIRC the woody installer does run dselect/tasksel at the end, but both don't install a new kernel by default. Worse, the install kernel is not contained in a package, so even update from security.d.o won't install a newer kernel. As such there will be no patch for the boot floppy kernel. I guess the main problem is that building the boot floppies is [said to be] a very ugly piece of work. cheers - -- vbi -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB+cOFgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l61FwAn0unNuIETyOtcJUcWY7P/IwS KcHSAJ9wH2J0TrjK2epJow9j2nW9ilNHLA== =eZCu -END PGP SIGNATURE-
Re: [DSA 479-2] New Linux 2.4.18 packages fix local root exploit (i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 15 April 2004 11.56, Tim Nicholas wrote: On 04/15/04 20:05, Michelle Konzack wrote: Question: What about the Bootfloppies ? If I recall correctly it is assumed that users will not run on the boot floppy kernels after the initial system installation. They are expected to install a more appropriate kernel after finishing the install. But who tells them? IIRC the woody installer does run dselect/tasksel at the end, but both don't install a new kernel by default. Worse, the install kernel is not contained in a package, so even update from security.d.o won't install a newer kernel. As such there will be no patch for the boot floppy kernel. I guess the main problem is that building the boot floppies is [said to be] a very ugly piece of work. cheers - -- vbi -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAkB+cOFgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l61FwAn0unNuIETyOtcJUcWY7P/IwS KcHSAJ9wH2J0TrjK2epJow9j2nW9ilNHLA== =eZCu -END PGP SIGNATURE-
netkit-inetd / time (port 37) related issues?
Hi, I just noticed that my machine got hammered (well, at 25kbps) with tons of port 37 connections for the past week. Anything known regarding recent security problems with that? I run a quite-up-to-date testing machine, and I follow the Debian DSAs and take action where the lacking security support for testing requires me to do so, so it shouldn't be a known old problem. To be careful, I have now reinstalled kernel, libc, psutils, coreutils and sysvinit from known-good sources. Newest chkrootkit Debian pkg doesn't detect anything, and after reboot the traffic has stopped. (Oh, yes: time service has also be disabled in inetd.conf) cheers -- vbi -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. pgp0.pgp Description: signature
netkit-inetd / time (port 37) related issues?
Hi, I just noticed that my machine got hammered (well, at 25kbps) with tons of port 37 connections for the past week. Anything known regarding recent security problems with that? I run a quite-up-to-date testing machine, and I follow the Debian DSAs and take action where the lacking security support for testing requires me to do so, so it shouldn't be a known old problem. To be careful, I have now reinstalled kernel, libc, psutils, coreutils and sysvinit from known-good sources. Newest chkrootkit Debian pkg doesn't detect anything, and after reboot the traffic has stopped. (Oh, yes: time service has also be disabled in inetd.conf) cheers -- vbi -- The content of this message may or may not reflect the opinion of me, my employer, my girlfriend, my cat or anybody else, regardless of the fact whether such an employer, girlfriend, cat, or anybody else exists. I (or my employer, girlfriend, cat or whoever) disclaim any legal obligations resulting from the above message. You, as the reader of this message, may or may not have the permission to redistribute this message as a whole or in parts, verbatim or in modified form, or to distribute any message at all. pgpJpxIuDPysr.pgp Description: signature
Re: Positive press for Debian's security team
On Wednesday 31 March 2004 01.22, Jones wrote: Michael: [Jones, please leave attributions in email] That's positive? They put us in the same category as Microsoft! This will lose us some serious street cred. :) it will lose us some street cred, but an equal amount will be gained on that other street, Wall Street :- So we expect DEB to be up by 20% tomorrow? :-) -- vbi -- Lo scopo e' scopare. -- Paolo Gonella pgp3s6BgLpWKU.pgp Description: signature
Re: Positive press for Debian's security team
On Wednesday 31 March 2004 01.22, Jones wrote: Michael: [Jones, please leave attributions in email] That's positive? They put us in the same category as Microsoft! This will lose us some serious street cred. :) it will lose us some street cred, but an equal amount will be gained on that other street, Wall Street :- So we expect DEB to be up by 20% tomorrow? :-) -- vbi -- Lo scopo e' scopare. -- Paolo Gonella pgp0.pgp Description: signature
Re: name based virtual host and apache-ssl - thanx
On Thursday 25 March 2004 10.12, Haim Ashkenazi wrote: [...] decided to buy certificate from versign [...] [ok, this goes offtopic.sorry.] You sure about that? Verisign is the company who break DNS (yes, the world wide DNS. Not just their servers. Well, it *was* their servers, but that's exactly the problem) in some respect to increase their profit (search some tech news site for wildcard dns record), were forced to undo that, and announced they would do it again in the near future. Verisign is the company who sold a certificate for microsoft.com to some joe random - so I guess somebody might do the same for your site.. Verisign is the company who routinely spams people who try to change their domain name registration to a different provider, or who have done so in the past. [I think their 'separating out' the registry business and all this is a technicality. It's still the same]. No, I won't name any other company here, and I'm not afiliated to any company selling certificates. cheers -- vbi -- There are never enough hours in a day, but always too many days before Saturday. pgp0.pgp Description: signature
Re: name based virtual host and apache-ssl - thanx
On Thursday 25 March 2004 10.12, Haim Ashkenazi wrote: [...] decided to buy certificate from versign [...] [ok, this goes offtopic.sorry.] You sure about that? Verisign is the company who break DNS (yes, the world wide DNS. Not just their servers. Well, it *was* their servers, but that's exactly the problem) in some respect to increase their profit (search some tech news site for wildcard dns record), were forced to undo that, and announced they would do it again in the near future. Verisign is the company who sold a certificate for microsoft.com to some joe random - so I guess somebody might do the same for your site.. Verisign is the company who routinely spams people who try to change their domain name registration to a different provider, or who have done so in the past. [I think their 'separating out' the registry business and all this is a technicality. It's still the same]. No, I won't name any other company here, and I'm not afiliated to any company selling certificates. cheers -- vbi -- There are never enough hours in a day, but always too many days before Saturday. pgpA4ZCxDMSoj.pgp Description: signature
Re: Linux clients in network - experiences?
Yo! On Saturday 20 March 2004 14.45, Cedric Ware wrote: [debian-security CC:ed since people there certainly have experience in the 'Server/network set up' section below. Please don't crosspost when you reply. Well, what about people subscribed to only one list but interested in both aspects of your message? :-) They can always read the list archive :-) [replying to both - I dunno which list you are on.] The main point I'd think of and that you may have missed would be software installation and maintenance. Don't assume it's something you only do once I wasn't mentioning it because I saw a thread or two discussing this a few months back, so I have quite a few pointers from there. http://www.infrastructures.org/ bookmarked - didn't know it. This doesn't solve the problem of installing new software / updating the configuration on multiple machines. A shared /usr/local can help for non-packaged software and for part of the configuration (symlinks from /etc for selected files). For the rest, one could use a special .deb whose installation scripts and dependency list makes the necessary changes, but alas I've not tried it yet. I've been doing the custom config .deb thing on a few machines, but not for long. I feel this can solve a lot of problems. Of course, you had better make sure not to be the only one who understands the system, unless you intend to work there forever with no vacations. :-) [NFS] Perhaps it can be secured if all traffic on your network is IPsec-based? I'm thinking about that - it would also solve most wifi-router and plugged-in laptop problems. - what is the color of my briefs? White and blue, separated along a diagonal? I'm from Basel, though, and just in Zürich because I have to (well, might be that my girlfriend has something to do with it, too). Thanks greets -- vbi -- featured link: http://fortytwo.ch/gpg/intro pgp0.pgp Description: signature
Re: Linux clients in network - experiences?
Yo! On Saturday 20 March 2004 14.45, Cedric Ware wrote: [debian-security CC:ed since people there certainly have experience in the 'Server/network set up' section below. Please don't crosspost when you reply. Well, what about people subscribed to only one list but interested in both aspects of your message? :-) They can always read the list archive :-) [replying to both - I dunno which list you are on.] The main point I'd think of and that you may have missed would be software installation and maintenance. Don't assume it's something you only do once I wasn't mentioning it because I saw a thread or two discussing this a few months back, so I have quite a few pointers from there. http://www.infrastructures.org/ bookmarked - didn't know it. This doesn't solve the problem of installing new software / updating the configuration on multiple machines. A shared /usr/local can help for non-packaged software and for part of the configuration (symlinks from /etc for selected files). For the rest, one could use a special .deb whose installation scripts and dependency list makes the necessary changes, but alas I've not tried it yet. I've been doing the custom config .deb thing on a few machines, but not for long. I feel this can solve a lot of problems. Of course, you had better make sure not to be the only one who understands the system, unless you intend to work there forever with no vacations. :-) [NFS] Perhaps it can be secured if all traffic on your network is IPsec-based? I'm thinking about that - it would also solve most wifi-router and plugged-in laptop problems. - what is the color of my briefs? White and blue, separated along a diagonal? I'm from Basel, though, and just in Zürich because I have to (well, might be that my girlfriend has something to do with it, too). Thanks greets -- vbi -- featured link: http://fortytwo.ch/gpg/intro pgpgTuPC68V8U.pgp Description: signature
Linux clients in network - experiences?
Yo! So far, my experience was with administrating smallish servers and mostly stand-alone clients. The future shines bright, however, and I may soon be in a position to do much more than that. But, lacking experience, I now need some advice. [debian-security CC:ed since people there certainly have experience in the 'Server/network set up' section below. Please don't crosspost when you reply. No need to CC me, I read both lists. Perhaps you also want to change the subject according to what you comment on.] Environment: typical office environment, no or few 'special' applications. 20-50 clients. Friendly $BOSS who hates M$, also, there's not much to migrate as this is pretty much start from scratch. (So it's quite an engineer's dream). Security is *very* important. Again, of course I don't expect HOWTO-type information, but opinions from people who have experience with different products - and in some case, I have not even an idea what products there are, so even this information will help. The RTFM part is of course for me to do. I mention mostly FOSS projects below, but I am not restricted, especially for finance/crm I suspect a commercial solution will be unavoidable. Recommendations/experiences sought all the more as evaluation is not as easy as 'apt-get install foo'. Office: I guess OpenOffice (or perhaps StarOffice) is more or less the default here. Perhaps some find that koffice or the gnome counterparts can realistically be considered (for people who will receive word/excel/pp documents from their customers etc.)? 'Collaborative work' - phpgroupware is often talked about. I guess it doesn't support GPG in the mailer, so my main question is: how useful is it without the mailer (sending conference requests etc.) ? Can its calendar and addressbook be used from other applications (dunno what the standards are in this field - webdav or ldap access?) - evolution is quite mature - but iirc it required a MS Outlook server for the calendar application to work for groups. Is this still true? - The KDE suite has hugely matured - at a first short glance, kontact seems to be just a shell for the various kdepim applications, so kontact's mail is really kmail. Again, the main question is about how well addressbook and calendar work for groups. Is there a server, what server is there, ...? - kroupware: I'm a bit confused. Is this mainly a server and will be integrated in KDE's kdepim tools, or is this seperate? From the web page, it seems it's a seperate project. Will it be merged into kdepim? Feature-wise, it looks quite good at a first glance (gpg support in mailer?) - wiki: which one? Focus on usability by people who have no idea what this is. Business software: - project management: taskjuggler - seems to be quite mature. Any others? - financial: sqlledger? How good is it really? How advanced is the thing in phpgroupware? Others? - crm: no idea here. I strongly suspect GNUe isn't up to the task yet without *much* development work. - ticketing: phpgroupware has one. request-tracker is quite good. double choco latte and bugzilla are available, too. I guess I'll just go with request-tracker since I know that a bit. Might be abused as a crm with a bit tweaking, I guess. Server/network set up - unix account management: I suspect NIS is not really an option in a security conscious environment (just hearsay, though, I'll look at it). Kerberos? With pam there should be no problem with integration. Others? - networked filesystem. NFS is certainly not the right tool here. AFS/Coda/Intermezzo? Or Lustre? Others? For this and the above, it would be nice if laptops could be integrated more or less nicely. Also, if the data would be encrypted on the wire this would be an added bonus. - authentication: I favor USB tokens (since ssh/pgp secret keys could be stored there, too). $BOSS wants fingerprint auth. What solutions do exist (I see there's an ITP out for libpam-usb. What about Linux-supported fingerprinting systems? Laptops?) - firewalls/routers: build my own, or buy? (I see an endless debate coming here :-) Hardware: - Dual head: what is available with good Linux support? How much tweaking does Debian (think sarge) need (KDE? Gnome?)? (Ok, this will change every few months, so I'll need to do that research again when this actually comes). - ok, this would be on the server side: RAID and hotswapping. I personally like software raid since I can swap controllers without problems. The software RAID HOWTO says it's possible with SCSI hardware, impossible to do reliably with IDE. This still true? (SATA?) Misc: - What experience do you have with setting the default locale to something like de_CH.UTF-8? Personally, I have quite a good impressions, but my primary tools are kmail, xterm, vi and konqueror - I rarely use any office applications. There will mostly be äöü, perhaps a few slavic characters. No right-to-left, cyrillic, chinese or korean
Linux clients in network - experiences?
Yo! So far, my experience was with administrating smallish servers and mostly stand-alone clients. The future shines bright, however, and I may soon be in a position to do much more than that. But, lacking experience, I now need some advice. [debian-security CC:ed since people there certainly have experience in the 'Server/network set up' section below. Please don't crosspost when you reply. No need to CC me, I read both lists. Perhaps you also want to change the subject according to what you comment on.] Environment: typical office environment, no or few 'special' applications. 20-50 clients. Friendly $BOSS who hates M$, also, there's not much to migrate as this is pretty much start from scratch. (So it's quite an engineer's dream). Security is *very* important. Again, of course I don't expect HOWTO-type information, but opinions from people who have experience with different products - and in some case, I have not even an idea what products there are, so even this information will help. The RTFM part is of course for me to do. I mention mostly FOSS projects below, but I am not restricted, especially for finance/crm I suspect a commercial solution will be unavoidable. Recommendations/experiences sought all the more as evaluation is not as easy as 'apt-get install foo'. Office: I guess OpenOffice (or perhaps StarOffice) is more or less the default here. Perhaps some find that koffice or the gnome counterparts can realistically be considered (for people who will receive word/excel/pp documents from their customers etc.)? 'Collaborative work' - phpgroupware is often talked about. I guess it doesn't support GPG in the mailer, so my main question is: how useful is it without the mailer (sending conference requests etc.) ? Can its calendar and addressbook be used from other applications (dunno what the standards are in this field - webdav or ldap access?) - evolution is quite mature - but iirc it required a MS Outlook server for the calendar application to work for groups. Is this still true? - The KDE suite has hugely matured - at a first short glance, kontact seems to be just a shell for the various kdepim applications, so kontact's mail is really kmail. Again, the main question is about how well addressbook and calendar work for groups. Is there a server, what server is there, ...? - kroupware: I'm a bit confused. Is this mainly a server and will be integrated in KDE's kdepim tools, or is this seperate? From the web page, it seems it's a seperate project. Will it be merged into kdepim? Feature-wise, it looks quite good at a first glance (gpg support in mailer?) - wiki: which one? Focus on usability by people who have no idea what this is. Business software: - project management: taskjuggler - seems to be quite mature. Any others? - financial: sqlledger? How good is it really? How advanced is the thing in phpgroupware? Others? - crm: no idea here. I strongly suspect GNUe isn't up to the task yet without *much* development work. - ticketing: phpgroupware has one. request-tracker is quite good. double choco latte and bugzilla are available, too. I guess I'll just go with request-tracker since I know that a bit. Might be abused as a crm with a bit tweaking, I guess. Server/network set up - unix account management: I suspect NIS is not really an option in a security conscious environment (just hearsay, though, I'll look at it). Kerberos? With pam there should be no problem with integration. Others? - networked filesystem. NFS is certainly not the right tool here. AFS/Coda/Intermezzo? Or Lustre? Others? For this and the above, it would be nice if laptops could be integrated more or less nicely. Also, if the data would be encrypted on the wire this would be an added bonus. - authentication: I favor USB tokens (since ssh/pgp secret keys could be stored there, too). $BOSS wants fingerprint auth. What solutions do exist (I see there's an ITP out for libpam-usb. What about Linux-supported fingerprinting systems? Laptops?) - firewalls/routers: build my own, or buy? (I see an endless debate coming here :-) Hardware: - Dual head: what is available with good Linux support? How much tweaking does Debian (think sarge) need (KDE? Gnome?)? (Ok, this will change every few months, so I'll need to do that research again when this actually comes). - ok, this would be on the server side: RAID and hotswapping. I personally like software raid since I can swap controllers without problems. The software RAID HOWTO says it's possible with SCSI hardware, impossible to do reliably with IDE. This still true? (SATA?) Misc: - What experience do you have with setting the default locale to something like de_CH.UTF-8? Personally, I have quite a good impressions, but my primary tools are kmail, xterm, vi and konqueror - I rarely use any office applications. There will mostly be äöü, perhaps a few slavic characters. No right-to-left, cyrillic, chinese or korean
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Saturday 21 February 2004 01.10, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? Absolutely none. The proposed reorganization was basically to create a new security team out of thin air, not tell them about anything, and expect bugfixes sooner. It was nonsense. [misinformation about CERT deleted] Sorry for that - replace CERT by $GROUP_OF_VENDORS in all places. I was under the impression CERT did the coordinating. I should do the research, I know... Those last two cases are equivalent. Think about it. The former is entity publishes information. The latter is entity discloses information to a 'select' group of people which then turns around and publishes it. Yes, that's the only difference. Why would anyone do that instead of publishing the information themselves? If they wanted it to be widely known, they would make it so. People do things for the strangest of reasons... I just thought that this would be the only scenario where I could think that a split security team could possibly act differently than the current security team. And it's only *could* act differently - so we have a very unlikely scenario, so this shows that the proposal to split the security team (or create a 2nd team, whatever) is really stupid. cheers -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgp0.pgp Description: signature
Re: Some clarifications about the Debian-security-HOWTO
On Saturday 21 February 2004 01.14, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. The only sensible way to handle this is the current way: stating 'testing has now security support'. urgency='high' or not. I run a stable/testing/unstable mix on my computers, and when a DSA is out I take a quick look and check which versions of the package I use. Downgrading a package from a testing version to a stable version is sometimes an option, for example. cheers -- vbi -- Entre hermanos, dos testigos y un notario. pgp0.pgp Description: signature
Re: DSA 438 - bad server time, bad kernel version or information delayed?
On Saturday 21 February 2004 01.10, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 02:34:37PM +0100, Adrian von Bidder wrote: I think this is the time where I'd like to see some hard data. Which DSA's would possibly have been released differently if such a reorganisation would have been in place? Absolutely none. The proposed reorganization was basically to create a new security team out of thin air, not tell them about anything, and expect bugfixes sooner. It was nonsense. [misinformation about CERT deleted] Sorry for that - replace CERT by $GROUP_OF_VENDORS in all places. I was under the impression CERT did the coordinating. I should do the research, I know... Those last two cases are equivalent. Think about it. The former is entity publishes information. The latter is entity discloses information to a 'select' group of people which then turns around and publishes it. Yes, that's the only difference. Why would anyone do that instead of publishing the information themselves? If they wanted it to be widely known, they would make it so. People do things for the strangest of reasons... I just thought that this would be the only scenario where I could think that a split security team could possibly act differently than the current security team. And it's only *could* act differently - so we have a very unlikely scenario, so this shows that the proposal to split the security team (or create a 2nd team, whatever) is really stupid. cheers -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) pgpbSRELG0xT2.pgp Description: signature
Re: Some clarifications about the Debian-security-HOWTO
On Saturday 21 February 2004 01.14, Matt Zimmerman wrote: On Fri, Feb 20, 2004 at 01:14:43PM +0100, Gian Piero Carrubba wrote: Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? It will reduce the best-case delay, but if the package is blocked from entering testing by its dependency relationships, the urgency does not change that. ... and sometimes people forget to leave urgency at 'high' until the fix is really in testing when they upload a new version. The only sensible way to handle this is the current way: stating 'testing has now security support'. urgency='high' or not. I run a stable/testing/unstable mix on my computers, and when a DSA is out I take a quick look and check which versions of the package I use. Downgrading a package from a testing version to a stable version is sometimes an option, for example. cheers -- vbi -- Entre hermanos, dos testigos y un notario. pgpjQFE2idzaE.pgp Description: signature
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On Friday 20 February 2004 07.58, Matt Zimmerman wrote: For the stable distribution (woody) these problems have been fixed in version 4.1.0-16woody3. For the unstable distribution (sid) these problems have been fixed in version 4.3.0-2. So this opens the questions - when will 4.3 hit testing? Was there recent summary? - is it worth it to upgrade now from testing? Stability? Performance? OTOH, I guess the DSA is not urgent at all as my workstations are single-user with no remote X configured. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgp0.pgp Description: signature
Re: [SECURITY] [DSA 443-1] New xfree86 packages fix multiple vulnerabilities
With the current thread in this list: thanks, Matt team - I'm quite satisfies with the way Debian handles security updates currently. And some people need to remind themselves that Debian is a volounteer project and is open source - so, if you want more/faster security updates, hire somebody to do it for you, and if you're feeling generous, allow this person to contribute his(her) efforts back to Debian. On Friday 20 February 2004 07.58, Matt Zimmerman wrote: For the stable distribution (woody) these problems have been fixed in version 4.1.0-16woody3. For the unstable distribution (sid) these problems have been fixed in version 4.3.0-2. So this opens the questions - when will 4.3 hit testing? Was there recent summary? - is it worth it to upgrade now from testing? Stability? Performance? OTOH, I guess the DSA is not urgent at all as my workstations are single-user with no remote X configured. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgpLxiy3u0oRN.pgp Description: signature
Re: security
On Wednesday 18 February 2004 02.31, [EMAIL PROTECTED] wrote: who is at fault? I am. -- Cosa invecchia presto? La gratitudine. -- Aristotele pgp0.pgp Description: signature
Re: security
On Wednesday 18 February 2004 02.31, [EMAIL PROTECTED] wrote: who is at fault? I am. -- Cosa invecchia presto? La gratitudine. -- Aristotele pgpjaCCuYCccE.pgp Description: signature
Re: GnuPG can not read some pgp signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clinging to sanity, LeVA mumbled in his beard: Reason: No appropriate crypto plug-in was found. Hi, I guess that your problem is NOT idea, but inline gpg signed msgs (like this one) versus PGP/MIME signed messages. There is currently no official gpg-agent and pinentry Debian packages, so you'll need to either get some unofficial ones (did anybody do any lately? I think Ralf Nolden's packages are not online anymore), or compile the software yourself as per [1] (last I tried, I had to disable threading on some components. But it's been a while, and new releases of most parts are out, so I don't know what the current status is). Greetings - -- vbi [1] http://kmail.kde.org/kmail-pgpmime-howto.html - -- Protect your privacy - encrypt your email: http://fortytwo.ch/gpg/intro -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAj/7tpJgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fW9IUAnA5gbmjLW2jKye7xLCJOTv4L IAlsAKC+aho9Af526mxbicP5t9nd8zzzUA== =XZ8c -END PGP SIGNATURE-
Re: Content-Type in DSAs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clinging to sanity, Alexander Neumann mumbled in his beard: Hi Lupe, * Lupe Christoph [EMAIL PROTECTED] wrote: Comparing the DSAs and reading how mutt recognizes a PGP signed message, I found that only some DSAs from Martin Schulze have a Content-Type as mutt wants it: Content-Type: application/pgp; format=text; x-action=sign - PGP/MIME No. PGP/MIME is multipart/signed on the top level, whatever the mime type of the message is in the first MIME part, and application/pgp-signature in the second MIME part. application/pgp is a never standardized text/plain variant of an inline signed message, with the main problem that some Mailers do not render it correctly (since they assume that unknown application/... is binary, not text). cheers - -- vbi - -- Protect your privacy - encrypt your email: http://fortytwo.ch/gpg/intro -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) Comment: get my key from http://fortytwo.ch/gpg/92082481 iKcEARECAGcFAj/66Z1gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fW+fIAmwfWDDM5RrsGtL24ODdRR3F4 pcMjAJ4iMmHa57/EfFh6bzjHSmnWB1k8jw== =FjWH -END PGP SIGNATURE-
Re: Keeping files away from users
On Thursday 05 June 2003 17:16, Peter Cordes wrote: kernel. (Even if you put the password in the kernel, you want to hide the initrd, because it will have mount(8) getting a password from /proc/sekret, or something.) Use some sort of encrypted filesystem on the hard drive. When you're hacking the kernel already, you don't need /proc/sekret: just take a kernel-space encrypted filesystem and hack it to automatically take the 5up3r 53kr3t p4zzw0rd when the type of the fs to be mounted is 'encrypted' (abuse the partition table fs type field). As others have said: don't tell anybody what you're doing - from a security point of view it is totally ridiculous. But it should foil the casual nosy guy. greets -- vbi -- random link of the day: http://fortytwo.ch/sienapei/laejieng pgpKIpImicSsj.pgp Description: signature
Re: Recommended security management packages
On Friday 23 May 2003 15:32, Phillip Hofmeister wrote: Your policy/rules should[...] Since you're discussing firewalls... My setup currently is basically forbid everything coming in (except ESTABLISHED, RELATED in iptables terms) and allow everything going out. This is on my home network, meaning I know all the machines here and know that I can trust all people here (me and the SO), are there any (obvious?) things I have not thought about? No windows clients, so I'm not worried about trojans since Linux trojans have been extremely rare so far. greets -- vbi -- featured product: GNU Privacy Guard - http://gnupg.org pgpmJTrGEbEZr.pgp Description: signature
Re: Spam
On Sunday 18 May 2003 19:41, Janus N. wrote: On Sun, 2003-05-18 at 03:43, Phillip Hofmeister wrote: With that point aside, you can try out bogofilters and razor. Between the two of those I have few false positive and few false negatives. Spamassassin already utilizes razor -- so razor failed that mail as well. Or razor was temporarily not reachable? Or razor was disabled on this particular installation? cheers -- vbi -- That's right; the upper-case shift works fine on the screen, but they're not coming out on the damn printer... Hold? Sure, I'll hold. -- e.e. cummings last service call pgpa52aR7u6ZK.pgp Description: signature
Re: Please clarifiy: kernel-sources / ptracebug / debian security announcenments
On Wednesday 07 May 2003 14:53, Peter Holm wrote: The actual kernel sources that one can get via apt-get, are they already patched? I have to admit that I didn't follow this issue closely, you'll have to get this info elsewhere. And: which informtion sources do I have to follow to become informed about *all* security bugs in debian? I fear there's no such place. The security announcements are only made when a fixed package is released, and to my knowledge there is no centralized debian specific place to get security announcements for security bugs where no patch is (yet) available. This is unfortunate, but I guess it cannot be changed as the security team reputedly is quite heavily loaded even now. greets -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg pgpdOI8IGWLE2.pgp Description: signature
Re: Logcheck, Logsentry, LogRider etc.
On Mon, 2003-03-31 at 01:24, Thomas Ritter wrote: Am Montag, 31. März 2003 00:27 schrieb Jan-Hendrik Palic: I am using logcheck, personally installed on my Debian-Server/WS, because, there are no debian-packages .. :( I don't know about sarge and woody, but logcheck in sid, roughly preconfigured for debian systems. It's there, also in stable. And, more important, more and more packages bring their own /etc/logcheck/ignore.d* files, so the logcheck maintainer doesn't have to jump after every log-producing daemon. Works fine here. -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part
Re: Logcheck, Logsentry, LogRider etc.
On Mon, 2003-03-31 at 01:24, Thomas Ritter wrote: Am Montag, 31. März 2003 00:27 schrieb Jan-Hendrik Palic: I am using logcheck, personally installed on my Debian-Server/WS, because, there are no debian-packages .. :( I don't know about sarge and woody, but logcheck in sid, roughly preconfigured for debian systems. It's there, also in stable. And, more important, more and more packages bring their own /etc/logcheck/ignore.d* files, so the logcheck maintainer doesn't have to jump after every log-producing daemon. Works fine here. -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part
Re: Removing invalid keys from keyring
On Thu, 2003-03-27 at 08:53, Lars Ellenberg wrote: gpg --list-public-keys | grep ^pub | sort tmp.pubkey_list cut -d -f 5- tmp.pubkey_list Be careful with gpg --list format - it may be different for some keys (with some flags set, v2/v3/v4 keys, ...). Better use the --with-colons format, field order should never change then. cheers -- vbi -- I'd like to meet the guy who invented beer and see what he's working on now. signature.asc Description: This is a digitally signed message part
Re: Removing invalid keys from keyring
On Thu, 2003-03-27 at 08:53, Lars Ellenberg wrote: gpg --list-public-keys | grep ^pub | sort tmp.pubkey_list cut -d -f 5- tmp.pubkey_list Be careful with gpg --list format - it may be different for some keys (with some flags set, v2/v3/v4 keys, ...). Better use the --with-colons format, field order should never change then. cheers -- vbi -- I'd like to meet the guy who invented beer and see what he's working on now. signature.asc Description: This is a digitally signed message part
Re: is iptables enough?
On Thu, 2003-03-20 at 22:10, Vineet Kumar wrote: * Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [20030320 06:39 PST]: Set it up to block everything and then selectively open ports until everything works as desired. Depending on the applications it may be a good idea to REJECT auth (identd) packets instead of dropping them - some applications have long timeouts. IMO, it's a good idea to REJECT instead of DROPping most packets. If you think DROPping makes you invisible, you're deluding yourself. I generally end my INPUT chain with I'm not invisible (you can even ping most of my machines). - DROP takes less bandwidth than REJECT. - DROP slows down nimda/code-red style trojans as they wait for the connect timeout, so it's actually friendly to your neighbours. back when code-red was all new and shiny, I got 10 connects per second, and that was just a 256/64k cable link. while we're at it, people may want to read and comment on my config (way OT - so ignore it if you're not interested) ppp0 is the outside world (pppoe over eth1). Port 6346 is gnutella, port 11372 is pgp keyserver related (not hkp), thefirewall box runs a mailserver from the inside and a teergrube on 4 accessible from the outside. If you read the mail headers, you know which box it is, too. [EMAIL PROTECTED]:~# iptables-save # Generated by iptables-save v1.2.7a on Fri Mar 21 10:13:12 2003 *nat :PREROUTING ACCEPT [17038:1364291] :POSTROUTING ACCEPT [1561:131055] :OUTPUT ACCEPT [7155:558179] -A PREROUTING -i ppp0 -p tcp -m tcp --dport 25 -j REDIRECT --to-ports 4 -A PREROUTING -i ppp0 -p tcp -m tcp --dport 11372 -j DNAT --to-destination 192.168.1.17 -A PREROUTING -i ppp0 -p tcp -m tcp --dport 6346 -j DNAT --to-destination 192.168.1.17 -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Fri Mar 21 10:13:12 2003 # Generated by iptables-save v1.2.7a on Fri Mar 21 10:13:12 2003 *filter :INPUT DROP [1323:393571] :FORWARD DROP [0:0] :OUTPUT ACCEPT [399596:206648275] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i ! ppp0 -j ACCEPT -A INPUT -p udp -m udp --dport 123 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 10/min -j ACCEPT -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -m tcp --dport 4 -j ACCEPT -A INPUT -i ppp0 -p udp -m udp --dport 137 -j DROP -A INPUT -m limit --limit 20/hour --limit-burst 50 -j LOG --log-prefix iptables:INPUT -A FORWARD -i ! ppp0 -m state --state NEW -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p tcp -m tcp --dport 11372 -j ACCEPT -A FORWARD -p tcp -m tcp --dport 6346 -j ACCEPT -A FORWARD -m limit --limit 20/hour --limit-burst 50 -j LOG --log-prefix iptables:FORWARD COMMIT # Completed on Fri Mar 21 10:13:12 2003 -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: is iptables enough?
On Thu, 2003-03-20 at 22:10, Vineet Kumar wrote: * Adrian 'Dagurashibanipal' von Bidder [EMAIL PROTECTED] [20030320 06:39 PST]: Set it up to block everything and then selectively open ports until everything works as desired. Depending on the applications it may be a good idea to REJECT auth (identd) packets instead of dropping them - some applications have long timeouts. IMO, it's a good idea to REJECT instead of DROPping most packets. If you think DROPping makes you invisible, you're deluding yourself. I generally end my INPUT chain with I'm not invisible (you can even ping most of my machines). - DROP takes less bandwidth than REJECT. - DROP slows down nimda/code-red style trojans as they wait for the connect timeout, so it's actually friendly to your neighbours. back when code-red was all new and shiny, I got 10 connects per second, and that was just a 256/64k cable link. while we're at it, people may want to read and comment on my config (way OT - so ignore it if you're not interested) ppp0 is the outside world (pppoe over eth1). Port 6346 is gnutella, port 11372 is pgp keyserver related (not hkp), thefirewall box runs a mailserver from the inside and a teergrube on 4 accessible from the outside. If you read the mail headers, you know which box it is, too. [EMAIL PROTECTED]:~# iptables-save # Generated by iptables-save v1.2.7a on Fri Mar 21 10:13:12 2003 *nat :PREROUTING ACCEPT [17038:1364291] :POSTROUTING ACCEPT [1561:131055] :OUTPUT ACCEPT [7155:558179] -A PREROUTING -i ppp0 -p tcp -m tcp --dport 25 -j REDIRECT --to-ports 4 -A PREROUTING -i ppp0 -p tcp -m tcp --dport 11372 -j DNAT --to-destination 192.168.1.17 -A PREROUTING -i ppp0 -p tcp -m tcp --dport 6346 -j DNAT --to-destination 192.168.1.17 -A POSTROUTING -o ppp0 -j MASQUERADE COMMIT # Completed on Fri Mar 21 10:13:12 2003 # Generated by iptables-save v1.2.7a on Fri Mar 21 10:13:12 2003 *filter :INPUT DROP [1323:393571] :FORWARD DROP [0:0] :OUTPUT ACCEPT [399596:206648275] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i ! ppp0 -j ACCEPT -A INPUT -p udp -m udp --dport 123 -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 10/min -j ACCEPT -A INPUT -p tcp -m tcp --dport 113 -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -m tcp --dport 4 -j ACCEPT -A INPUT -i ppp0 -p udp -m udp --dport 137 -j DROP -A INPUT -m limit --limit 20/hour --limit-burst 50 -j LOG --log-prefix iptables:INPUT -A FORWARD -i ! ppp0 -m state --state NEW -j ACCEPT -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -p tcp -m tcp --dport 11372 -j ACCEPT -A FORWARD -p tcp -m tcp --dport 6346 -j ACCEPT -A FORWARD -m limit --limit 20/hour --limit-burst 50 -j LOG --log-prefix iptables:FORWARD COMMIT # Completed on Fri Mar 21 10:13:12 2003 -- vbi -- OpenPGP encrypted mail welcome - my key: http://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: is iptables enough?
On Wed, 2003-03-19 at 23:01, Stefan Neufeind wrote: What I find astonishing: Let's say you are running a webserver, maybe mailserver and a DNS on a server. What rules do you want to apply to the packets etc.? I guess plain iptables should be enough for single PC or SOHO network - you can do pretty much everything. What I have not investigated is reporting - as iptables has no builtin (canonical) fancy reporting software, you'd rely on add-on software, and I don't know what's available there. To the original poster: Do it all with iptables. Set it up to block everything and then selectively open ports until everything works as desired. Depending on the applications it may be a good idea to REJECT auth (identd) packets instead of dropping them - some applications have long timeouts. Server hardware: a 486/25 with 36M RAM should be able to bear the load you're describing (it did for me, for several years, and still does for the people now living there, including also routing and squid proxy for the 3 computers behind it. The only thing is that you'd want to avoid compiling kernels on that machine :-) To make your life as care-free as possible: install woody, not testing - you don't really need the latest software, do you - and subscribe to the security announcement list. Think about partitioning your server - log files at least, and perhaps mail spool, too, should go into a partition of their own, and use some softwrae to monitor disk useage (there's software for this, but there's also the method of just calling 'df' from a cron script). Use logcheck or some similar software - once you've tuned it to your needs, you'll have almost no mail during regular operation. pflogsumm or similar could be interesting if you want an overview of what your mailserver is doing, it'll not react fast enough if your server is ever abused, though. For the website, running webalize or somesuch is interesting, I have made the experience (with church authorities, as it happens) that the not so tech-savvy are mightily impressed if you can show them that 4 or 5 actual people really look at the web page. cheers -- vbi -- The prablem with Manoca is thot it's difficult ta tell the difference between o cauple af the letters. -- Jacob W. Haller on alt.religion.kibology signature.asc Description: This is a digitally signed message part
Re: is iptables enough?
On Wed, 2003-03-19 at 23:01, Stefan Neufeind wrote: What I find astonishing: Let's say you are running a webserver, maybe mailserver and a DNS on a server. What rules do you want to apply to the packets etc.? I guess plain iptables should be enough for single PC or SOHO network - you can do pretty much everything. What I have not investigated is reporting - as iptables has no builtin (canonical) fancy reporting software, you'd rely on add-on software, and I don't know what's available there. To the original poster: Do it all with iptables. Set it up to block everything and then selectively open ports until everything works as desired. Depending on the applications it may be a good idea to REJECT auth (identd) packets instead of dropping them - some applications have long timeouts. Server hardware: a 486/25 with 36M RAM should be able to bear the load you're describing (it did for me, for several years, and still does for the people now living there, including also routing and squid proxy for the 3 computers behind it. The only thing is that you'd want to avoid compiling kernels on that machine :-) To make your life as care-free as possible: install woody, not testing - you don't really need the latest software, do you - and subscribe to the security announcement list. Think about partitioning your server - log files at least, and perhaps mail spool, too, should go into a partition of their own, and use some softwrae to monitor disk useage (there's software for this, but there's also the method of just calling 'df' from a cron script). Use logcheck or some similar software - once you've tuned it to your needs, you'll have almost no mail during regular operation. pflogsumm or similar could be interesting if you want an overview of what your mailserver is doing, it'll not react fast enough if your server is ever abused, though. For the website, running webalize or somesuch is interesting, I have made the experience (with church authorities, as it happens) that the not so tech-savvy are mightily impressed if you can show them that 4 or 5 actual people really look at the web page. cheers -- vbi -- The prablem with Manoca is thot it's difficult ta tell the difference between o cauple af the letters. -- Jacob W. Haller on alt.religion.kibology signature.asc Description: This is a digitally signed message part
new pam error message in logs
Hi! The symptoms are: Mar 17 14:08:20 syydelaervli pam_limits[24325]: setrlimit limit #7 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0 Mar 17 14:09:09 syydelaervli pam_limits[24332]: setrlimit limit #7 to soft=-1, hard=-1 failed: Operation not permitted; uid=0 euid=0 [EMAIL PROTECTED]:~# dpkg -l libpam0g libc6 ssh Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libpam0g 0.76-9 Pluggable Authentication Modules library ii libc6 2.3.1-14 GNU C Library: Shared libraries and Timezone ii ssh3.4p1-4Secure rlogin/rsh/rcp replacement (OpenSSH) [EMAIL PROTECTED]:~# I get these messages occasionally, the process in question is ssh (after authenticating with pubkey and the 'session opened for user ...' message). I didn't get them before the last pam libc upgrade, but I haven't got an idea what versions were there. any ideas? cheers -- vbi -- Debian is the Jedi operating system: Always two there are, a master and an apprentice. -- Simon Richter on debian-devel signature.asc Description: This is a digitally signed message part
Re: Traffic monitoring
On Sat, 2003-03-15 at 00:22, Stefan Neufeind wrote: Is there any good way to account traffic on one computer by user? I Hmmm. As long as you have specific protocols, you could always parse the server logs. ftp and http should be no problem, most daemons write a sensible log, I guess. Others (especially IMAP) I don't know. SSH probably doesn't write such a log. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part
Re: Traffic monitoring
On Sat, 2003-03-15 at 00:22, Stefan Neufeind wrote: Is there any good way to account traffic on one computer by user? I Hmmm. As long as you have specific protocols, you could always parse the server logs. ftp and http should be no problem, most daemons write a sensible log, I guess. Others (especially IMAP) I don't know. SSH probably doesn't write such a log. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA 253-1] New OpenSSL packages fix timing-basedattack vulnerability
On Mon, 2003-02-24 at 15:00, Martin Schulze wrote: For the old stable distribution (potato) this problem has been fixed in version 0.9.6c-0.potato.5. Please note that this updates the version from potato-proposed-updates that superseds the version in potato. Hmm. Now that a date is being set for stopping potato security support (if I read that thread correctly), how about mentioning this in every sinlge DSA? WARNING: security support for the Debian 2.2 (potato) release will not be continued after blubberblubber. Please upgrade to the current stable 3.0 (woody) release. Something like that. Or would this just annoy people forced to stay with potato for some reasons (like having 4000 machines or so). cheers -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA 253-1] New OpenSSL packages fix timing-based attack vulnerability
On Mon, 2003-02-24 at 15:00, Martin Schulze wrote: For the old stable distribution (potato) this problem has been fixed in version 0.9.6c-0.potato.5. Please note that this updates the version from potato-proposed-updates that superseds the version in potato. Hmm. Now that a date is being set for stopping potato security support (if I read that thread correctly), how about mentioning this in every sinlge DSA? WARNING: security support for the Debian 2.2 (potato) release will not be continued after blubberblubber. Please upgrade to the current stable 3.0 (woody) release. Something like that. Or would this just annoy people forced to stay with potato for some reasons (like having 4000 machines or so). cheers -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 signature.asc Description: This is a digitally signed message part
Re: Sarge freeze and security updates
On Sun, 2003-02-23 at 19:25, Simon Huggins wrote: I don't see why people are worried about numbering for security patches for testing. Why wouldn't they be done in the same way that security patches are done at the moment? i.e 1.2.3-1.sarge.1 as the security fix for 1.2.3-1 Simple problem: foo 1.2-1 is in stable foo 1.3-1 in testing foo 1.4-1 is in unstable Security problem. foo 1.2-1.woody.1 goes to stable foo 1.3-1.sarge.1 goes to testing unstable is not fixed because the security patch for 1.3 does not apply cleanly, and anyway, it is expected that upsteam fixes this soon. Now, foo 1.4-1 moves to testing with the security problem still unfixed. Damn. In other words: all security problems would have to be closely watched for unstable, too, and this is not really possible. Yes, in many cases it wouldn't happen because the fix goes to both stable and unstable, but the case above will happen, and testing users with security updates would feel a safety that they don't have. cheers -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) signature.asc Description: This is a digitally signed message part
Re: Sarge freeze and security updates
On Mon, 2003-02-24 at 11:06, Peter Cordes wrote: On Mon, Feb 24, 2003 at 10:13:57AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: Now, foo 1.4-1 moves to testing with the security problem still unfixed. Damn. File a bug on foo 1.4-1 so that can't happen until the bug is closed? Having stuff which introduces new known security holes move into testing is obviously bad under all circumstances, right? Sure. The problem is: who files the bug? Would probably be the testing security team. But if the versions in testing and unstable diverge, I'm not sure if the security team is supposed to file a bug just so, or is obliged to additionally verify the version in unstable? (Of course, the divergence between testing and unstable now is somewhat special, so this case might not happen too frequently). -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 signature.asc Description: This is a digitally signed message part
Re: Sarge freeze and security updates
On Sun, 2003-02-23 at 19:25, Simon Huggins wrote: I don't see why people are worried about numbering for security patches for testing. Why wouldn't they be done in the same way that security patches are done at the moment? i.e 1.2.3-1.sarge.1 as the security fix for 1.2.3-1 Simple problem: foo 1.2-1 is in stable foo 1.3-1 in testing foo 1.4-1 is in unstable Security problem. foo 1.2-1.woody.1 goes to stable foo 1.3-1.sarge.1 goes to testing unstable is not fixed because the security patch for 1.3 does not apply cleanly, and anyway, it is expected that upsteam fixes this soon. Now, foo 1.4-1 moves to testing with the security problem still unfixed. Damn. In other words: all security problems would have to be closely watched for unstable, too, and this is not really possible. Yes, in many cases it wouldn't happen because the fix goes to both stable and unstable, but the case above will happen, and testing users with security updates would feel a safety that they don't have. cheers -- vbi -- Available for key signing in Zürich and Basel, Switzerland (what's this? Look at http://fortytwo.ch/gpg/intro) signature.asc Description: This is a digitally signed message part
Re: Sarge freeze and security updates
On Mon, 2003-02-24 at 11:06, Peter Cordes wrote: On Mon, Feb 24, 2003 at 10:13:57AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: Now, foo 1.4-1 moves to testing with the security problem still unfixed. Damn. File a bug on foo 1.4-1 so that can't happen until the bug is closed? Having stuff which introduces new known security holes move into testing is obviously bad under all circumstances, right? Sure. The problem is: who files the bug? Would probably be the testing security team. But if the versions in testing and unstable diverge, I'm not sure if the security team is supposed to file a bug just so, or is obliged to additionally verify the version in unstable? (Of course, the divergence between testing and unstable now is somewhat special, so this case might not happen too frequently). -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 signature.asc Description: This is a digitally signed message part
Re: BCC fields shown
On Sat, 2003-01-18 at 16:22, Csillag Kristóf wrote: Soren Boll Overgaard pointed out that deleting the BCC fields from the mails sent to other recipients is not the mail client's responsibility. It should be done by the MTA. ONLY, really ONLY if the MTA receives the mail per sendmail. I would be very angry if my MTA started to automatically modify the headers (apart from inserting Received: and so on) on mail that came in per SMTP. Distinction between envelope and header sender/adressee is there for a purpose, after all. cheers -- vbi -- Honk if you are against noise pollution! signature.asc Description: This is a digitally signed message part
Re: BCC fields shown
On Sat, 2003-01-18 at 16:22, Csillag Kristóf wrote: Soren Boll Overgaard pointed out that deleting the BCC fields from the mails sent to other recipients is not the mail client's responsibility. It should be done by the MTA. ONLY, really ONLY if the MTA receives the mail per sendmail. I would be very angry if my MTA started to automatically modify the headers (apart from inserting Received: and so on) on mail that came in per SMTP. Distinction between envelope and header sender/adressee is there for a purpose, after all. cheers -- vbi -- Honk if you are against noise pollution! signature.asc Description: This is a digitally signed message part
Re: FW: Updated OPENSSL package for Debian?
On Tue, 2003-01-07 at 16:00, Miles Beck wrote: Hello, Is there an updated OPENSSL package for Debian greater than OpenSSL-0.9.6c? ~/Net_SSLeay.pm-1.21$ perl Makefile.PL Checking for OpenSSL-0.9.6g or newer... You have OpenSSL-0.9.6c installed in /usr openssl-0.9.6d and earlier versions have security flaws, see advisory at www.openssl.org, upgrading to openssl-0.9.6g is recommended avbidder@altfrangg:~/.fortune$ apt-cache policy openssl openssl: Installed: (none) Candidate: 0.9.6g-6 Version Table: 0.9.6g-10 0 500 http://syydelaervli unstable/main Packages 0.9.6g-6 0 700 http://syydelaervli testing/main Packages 0.9.6c-2.woody.1 0 600 http://syydelaervli stable/updates/main Packages 0.9.6c-2 0 600 http://syydelaervli stable/main Packages So the version from testing should do. You may want to download the source package and compile it yourself to avoid having to upgrade dependencies (I don't know, just speculating). cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: FW: Updated OPENSSL package for Debian?
On Tue, 2003-01-07 at 19:16, Noah L. Meyerhans wrote: On Tue, Jan 07, 2003 at 05:08:23PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: So the version from testing should do. You may want to download the source package and compile it yourself to avoid having to upgrade dependencies (I don't know, just speculating). Why tell him that? What the hell is wrong with the version of openssl from security.debian.org? There are no known security vulnerabilities there. Advising somebody to install packages from *testing* to get security updates is very unwise. Doing so would prevent them from getting a new version of the package in the event that it's updated by the security team again. Some might feel more comfortable with installing a package from testing than with modifying version checks in a configure script. But I agree that I probably should have said that testing, of course, does not have security support as do the stable versions. cheers -- vbi -- featured product: SpamAssassin - http://spamassassin.org signature.asc Description: This is a digitally signed message part
Re: FW: Updated OPENSSL package for Debian?
On Tue, 2003-01-07 at 16:00, Miles Beck wrote: Hello, Is there an updated OPENSSL package for Debian greater than OpenSSL-0.9.6c? ~/Net_SSLeay.pm-1.21$ perl Makefile.PL Checking for OpenSSL-0.9.6g or newer... You have OpenSSL-0.9.6c installed in /usr openssl-0.9.6d and earlier versions have security flaws, see advisory at www.openssl.org, upgrading to openssl-0.9.6g is recommended [EMAIL PROTECTED]:~/.fortune$ apt-cache policy openssl openssl: Installed: (none) Candidate: 0.9.6g-6 Version Table: 0.9.6g-10 0 500 http://syydelaervli unstable/main Packages 0.9.6g-6 0 700 http://syydelaervli testing/main Packages 0.9.6c-2.woody.1 0 600 http://syydelaervli stable/updates/main Packages 0.9.6c-2 0 600 http://syydelaervli stable/main Packages So the version from testing should do. You may want to download the source package and compile it yourself to avoid having to upgrade dependencies (I don't know, just speculating). cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: FW: Updated OPENSSL package for Debian?
On Tue, 2003-01-07 at 19:16, Noah L. Meyerhans wrote: On Tue, Jan 07, 2003 at 05:08:23PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: So the version from testing should do. You may want to download the source package and compile it yourself to avoid having to upgrade dependencies (I don't know, just speculating). Why tell him that? What the hell is wrong with the version of openssl from security.debian.org? There are no known security vulnerabilities there. Advising somebody to install packages from *testing* to get security updates is very unwise. Doing so would prevent them from getting a new version of the package in the event that it's updated by the security team again. Some might feel more comfortable with installing a package from testing than with modifying version checks in a configure script. But I agree that I probably should have said that testing, of course, does not have security support as do the stable versions. cheers -- vbi -- featured product: SpamAssassin - http://spamassassin.org signature.asc Description: This is a digitally signed message part
Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
On Mon, 2003-01-06 at 21:06, Phillip Hofmeister wrote: On Mon, 06 Jan 2003 at 06:44:17PM +0100, Domonkos Czinke wrote: - Original Message - From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: bugtraq@securityfocus.com mailto:bugtraq@securityfocus.com Sent: Sunday, January 05, 2003 4:37 AM Subject: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS # gdb sshd 6552 This vulnerability seems to be useless if you have to be able to run gdb locally AS ROOT (as demonstrated above)... If I have root access to a machinewhy am I trying to exploit a vulnerability? The gdb session is proof of concept. Apparently it is possible to cause the same effect by carefully chosing the data on the sender. No, I've not studied it. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys signature.asc Description: This is a digitally signed message part
Re: Bad Signature (was: Re: SSH)
On Tue, 2002-12-17 at 22:57, Ryan Eby wrote: On Tue, 2002-12-17 at 05:00, Adrian 'Dagurashibanipal' von Bidder wrote: I get this same error. According to the security.debian.org FAQ, evolution is known to mess up the signatures: Most likely some piece of mail software on your end slightly changes the message that breaks the signature. Make sure your software does not do any MIME encoding or decoding, or tab/space conversions. Known culprits are fetchmail (with the mimedecode option enabled), formail (from procmail 3.14 only) and evolution. http://www.debian.org/security/faq#signature It would be helpful if that reference would include a version number. At the release of evo 1.2 ximian claimed that it fixed all known PGP issues. Apparently this isn't the case :-/ Anyway, thanks for participating, folks. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Bad Signature (was: Re: SSH)
On Tue, 2002-12-17 at 00:06, Kilian CAVALOTTI wrote: I'll start to point these things out cause I'm wondering if it's certain MUA combinations that always fail: gpg: armor header: Version: GnuPG v1.2.1 (MingW32) - GPGrelay v0.90 gpg: Signature made Tue Dec 17 00:06:47 2002 CET using DSA key ID D657340C gpg: armor header: Version: 5.0 gpg: armor header: Comment: PGP Key Server 0.9.4+patch2+JHpatch2 gpg: pub 1024D/D657340C 2001-10-15 Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] gpg: key D657340C: public key Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] imported gpg: Total number processed: 1 gpg: imported: 1 gpg: BAD signature from Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] This is evolution 1.2.0-2 and gnupg 1.2.1-2 on my end. MSOE 6.00.2800.1123at your end. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: SSH
On Tue, 2002-12-17 at 00:24, Edward Guldemond wrote: On Mon, Dec 16, 2002 at 05:52:15PM -0500, Phillip Hofmeister wrote: Hi all, I am sure you have seen the SSH CERT. Are we vulnerable? If so is there a time line for an update? Sorry for the last email. Spoke before I read. :-) According to the advisory[1]: Well, SSH1 is still vulnerable. It's nothing to do with the current advisory. So the advice not to run SSH1 is still valid. (I don't know any details about the SSH1 vulnerability, so don't ask me.) cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Bad Signature (was: Re: SSH)
On Tue, 2002-12-17 at 00:06, Kilian CAVALOTTI wrote: I'll start to point these things out cause I'm wondering if it's certain MUA combinations that always fail: gpg: armor header: Version: GnuPG v1.2.1 (MingW32) - GPGrelay v0.90 gpg: Signature made Tue Dec 17 00:06:47 2002 CET using DSA key ID D657340C gpg: armor header: Version: 5.0 gpg: armor header: Comment: PGP Key Server 0.9.4+patch2+JHpatch2 gpg: pub 1024D/D657340C 2001-10-15 Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] gpg: key D657340C: public key Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] imported gpg: Total number processed: 1 gpg: imported: 1 gpg: BAD signature from Kilian CAVALOTTI (Kick) [EMAIL PROTECTED] This is evolution 1.2.0-2 and gnupg 1.2.1-2 on my end. MSOE 6.00.2800.1123at your end. cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: SSH
On Tue, 2002-12-17 at 00:24, Edward Guldemond wrote: On Mon, Dec 16, 2002 at 05:52:15PM -0500, Phillip Hofmeister wrote: Hi all, I am sure you have seen the SSH CERT. Are we vulnerable? If so is there a time line for an update? Sorry for the last email. Spoke before I read. :-) According to the advisory[1]: Well, SSH1 is still vulnerable. It's nothing to do with the current advisory. So the advice not to run SSH1 is still valid. (I don't know any details about the SSH1 vulnerability, so don't ask me.) cheers -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg NOTE: keyserver bugs! get my key here: https://fortytwo.ch/gpg/92082481 signature.asc Description: This is a digitally signed message part
Re: how to identify the superuser in C
On Wed, 2002-12-11 at 03:58, Chris Shafer wrote: Hello, Some documentation I found helpful when I was doing something similar in [...] Just wondering... Content-Type: multipart/mixed instead of multipart/signed. Your mailer buggy? cheers -- vbi -- featured link: http://fortytwo.ch/smtp signature.asc Description: This is a digitally signed message part
Re: how to identify the superuser in C
On Wed, 2002-12-11 at 03:58, Chris Shafer wrote: Hello, Some documentation I found helpful when I was doing something similar in [...] Just wondering... Content-Type: multipart/mixed instead of multipart/signed. Your mailer buggy? cheers -- vbi -- featured link: http://fortytwo.ch/smtp signature.asc Description: This is a digitally signed message part
changelog.Debian and security advisories
Yo! Would it make sense if new packages uploaded as part of handling a DSA would include the DSA number in the changelog.Debian? When I do an upgrade after seeing a DSA, it's sometimes not enirely clear to me if it's already the version mentioned in the DSA or if my mirror did not pick it up yet. (Yes, I can check the version number, but usually that means I have to go back and look at the DSA again.) [cc: me please because I'll be away the next 2 weeks] cheers -- vbi -- secure email with gpg http://fortytwo.ch/gpg signature.asc Description: This is a digitally signed message part
Re: attack of the marsians
On Tue, 2002-06-11 at 19:48, Thomas Thurman wrote: On Tue, 11 Jun 2002, Proud Debian-User wrote: Jun 11 19:03:19 abyss kernel: martian source 10.10.150.1 from 10.10.151.43, on dev eth0 means broadcast; obviously that can't be a source address. I'm not sure how 10.10.150.1 can be considered invalid, though. Just guessing: does the kernel warn when the IP sender does not agree with the MAC of that host? (Of course, only if we're in the local net - this is usual for routed packets, obviously) cheers -- vbi -- secure email with gpg[EMAIL PROTECTED]: key id 0x92082481 [EMAIL PROTECTED]:key id 0x5E4B731F signature.asc Description: This is a digitally signed message part
Re: frequent mail signing = is there a GPG agent?
On Sun, 2002-06-09 at 04:57, Jean Christophe ANDRÃ wrote: Hello *, Probably a stupid question but... I can see lots of you on this list frequently signing their e-mails, do you use some kind of GPG agent? afaik gpg-agent is only just developping. Search gpg-devel list for it. btw, anybody knows why evolution (1.0.5-1) crashes whenever gpg tries to fetch a key from the keyserver? cheers -- vbi -- secure email with gpg[EMAIL PROTECTED]: key id 0x92082481 [EMAIL PROTECTED]:key id 0x5E4B731F signature.asc Description: This is a digitally signed message part
