Discuss February 2005

discuss@lists.centos.org

162 participants
187 discussions

Start a nNew thread

[Fwd: CentOS-3 i386 errata: Updated mod_python package fixes security issue]
by Lance Davis 10 Feb '05

10 Feb '05

arrgh

2 3

CentOS-3 i386 errata: Updated mod_python package fixes security issue
by Lance Davis 10 Feb '05

10 Feb '05

https://rhn.redhat.com/errata/RHSA-2005-104.html refers Updated files are :- updates/i386/RPMS/mod_python-3.0.3-5.ent.i386.rpm updates/i386/SRPMS/mod_python-3.0.3-5.ent.src.rpm To update run 'yum update mod_python' Lance

1 0

help with xargs and mv
by James B. Byrne 10 Feb '05

10 Feb '05

I am trying to move a group of sendmail queue files into a special area and am developing s script to assist. The manual steps are: # Identify which messages to move mailq -qR<domain> > file1 # Select only lines with message ID strings grep '^[[:alpha:]][[:alnum:]]\{13\}' file1 > file2 # extract only the messages ID cut -b -14 file2 > file3 # prepend '*' to message IDs sed "s/^/\*/" file3 > file4 All of this works the way that I expect. What I now want to do is to mv all of the related files listed in file4 in the form "*messageid" to another directory. Using xargs I expected (naively) that the following construction would work: cat file4 | xargs mv /var/spool/mqueue/'{}' \ /var/spool/mqueue/offline (note that in the original this is all one line.) However, when I do this I get the error: mv: when moving multiple files, last argument must be a directory Try `mv --help' for more information. There is obviously something about xargs that I do not understand. In my imagination I see this xargs construction expanding to this: mv /var/spool/mqueue/*messageid1 /var/spool/mqueue/offline mv /var/spool/mqueue/*messageid2 /var/spool/mqueue/offline . . . mv /var/spool/mqueue/*messageidn /var/spool/mqueue/offline so that the qf and df files for each message are moved into the subdirectory offline. But this is obviously incorrect. Can anyone here point out to me what my misunderstanding is and how to get this to work? If this is not the forum for this kind of question then can someone with more experience point me to a mailing list that would be more suitable? Regards, JIm -- *** e-mail is not a secure channel *** mailto:byrnejb.<token>@harte-lyne.ca James B. Byrne Harte & Lyne Limited vox: +1 905 561 1241 9 Brockley Drive fax: +1 905 561 0757 Hamilton, Ontario <token> = hal Canada L8E 3C3

4 12

Apache 2.0.53 and Centos
by Michael Rock 10 Feb '05

10 Feb '05

Can someone tell me what configure options are needed to compile the latest Apache 2.0.53 to behave exactly like the latest apache 2.0.46 included with Centos 3.4? thx __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

4 10

CentOS-3 x86_64 errata: Updated mailman packages fix security vulnerability
by Tru Huynh 10 Feb '05

10 Feb '05

https://rhn.redhat.com/errata/RHSA-2005-136.html refers updated files are :- updates/x86_64/RPMS/mailman-2.1.5-24.rhel3.x86_64.rpm updates/x86_64/SRPMS/mailman-2.1.5-24.rhel3.src.rpm To update CentOS 3 to this new version run 'yum update mailman' CentOS 3.3 shipped with an earlier version of mailman - mailman-2.0.13-5 - in the extras repo. Details of the mailman upgrade procedure may be found at http://www.centos.org/mailman The 3.3 x86_64 updates repository already contained a mailman-2.1.5-23, so the upgrade was also provided for 3.3 and 3.4. Consider upgrading to CentOS 3.4 (http://www.centos.org/modules/news/article.php?storyid=34) Tru -- Tru Huynh (CentOS-3 x86_64 helper) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

CentOS-3 i386 errata: Updated mailman packages fix security vulnerability
by Lance Davis 10 Feb '05

10 Feb '05

https://rhn.redhat.com/errata/RHSA-2005-136.html refers updated files are :- updates/i386/RPMS/mailman-2.1.5-24.rhel3.i386.rpm updates/i386/SRPMS/mailman-2.1.5-24.rhel3.src.rpm To update CentOS 3.4 to this new version run 'yum update mailman' CentOS 3.3 shipped with an earlier version of mailman - mailman-2.0.13-5 - in the extras repo. This version has not been supported since 3.4 was released, ( http://www.centos.org/modules/news/article.php?storyid=34) however this version may be vulnerable to the exploit so it is recommended that all users upgrade. Details of the upgrade procedure may be found at http://www.centos.org/mailman Lance

2 1

silly cross posts
by Rick Graves 10 Feb '05

10 Feb '05

Russ, > Sorry for the cross post, but this is an important > one potentially affecting all recipients. Why be sorry? Did you break a rule? Where is the rule? It seems that there is a rule, but the rule gives if the matter is important enough. But you have to say "Sorry"? It seems that when a matter comes up that is important enough to inform everyone, one MUST cross post -- otherwise, you guarantee that lots of people will not get the message. Having to say "Sorry" to get a message out to everyone who needs to get the message seems silly to me. I would think that if the message is important enough and must get to everyone, one should be able to cross post without having to say "Sorry" -- saying "Sorry" is "silly". Rick

1 0

Mailman crons
by Henk van Lingen 10 Feb '05

10 Feb '05

Hi, The last RHEL3 update pack contains a mailman package. I'm using that on a new mailserver and found a little problem with cron when starting/ stopping the mailman service. RedHat moves the mailman crontab in and out every time, however, crond only notes the 'move in', not the 'move out. This is because the /etc/cron.d/ timestamp only changes by a 'move in'. My fix: add rm -f $DST_CRON_SCRIPT as the first line in the function RemoveCron() in /etc/init.d/mailman. Cheers, -- Henk van Lingen, Systems & Network Administrator (o- -+ Dept. of Computer Science, Utrecht University. /\ | phone: +31-30-2535278 v_/_ http://henk.vanlingen.net/ http://www.tuxtown.net/netiquette/

1 0

[centos 3.4] e1000 and installation problem
by Martin Hamant 10 Feb '05

10 Feb '05

Hello, I install Centos'es from PXE, with vmlinuz and initrd provided by images/pxeboot from the first CD of centos 3.4. The server is a PowerEdge 1850 with two integrated e1000 nic interfaces. So kernel is booting, then it comes to the screen which ask for one nic to do a dhcp query. I choose eth0, dhcp server reply well and then i get an ip address, dns'es, etc. And nothing else happen because the nic link is going down at this point !!! (no light, no way. ) I've tried with PXE install of centos 3.3, and all is working fine on this server.... Do you think there is a problem with the centos 3.4 "installation time" kernel ? I remember that centos 3.1 had problems about this nic too ... Any ideas ? Thank you ! -- Martin

3 5

full-d] Administrivia: List Compromised due to Mailman Vulnerability (fwd)
by R P Herrold 09 Feb '05

09 Feb '05

Sorry for the cross post, but this is an important one potentially affecting all recipients. This just crossed the Full Disclosure mailman moderated mailing list. It bears a careful read, and thought about whether a response is needed. The implication is that if there is any use of a mailman password in common with a password you 'care' about, you need to take appropriate action at once. Also some backends merge Bugzilla and mailman password stores, which can cause unexpected secondary effects. I have not seen a patch yet, and so one has to assume that the configs and passwords for all mailman moderated mailing lists are compromised. Once a fix issues, Mailman moderators will want to do a global password change, and local list modification. -- Russ Herrold ---------- Forwarded message ---------- Date: Wed, 9 Feb 2005 18:15:02 +0000 From: John Cartwright <johnc(a)grok.org.uk> To: full-disclosure(a)lists.netsys.com Subject: full-d] Administrivia: List Compromised due to Mailman Vulnerability Hi On 7th February 2005 I was notified of a number of potentially - compromised Full-Disclosure subscriber accounts. Following an investigation it appears that the Mailman configuration database was obtained from lists.netsys.com on 2nd January 2005 using a remote directory traversal exploit for a previously unpublished vulnerability in Mailman 2.1.5. Subscriber addresses and passwords have been compromised. All list members are advised to change their password immediately. There do not appear to be further signs of intrusion although investigations continue. The vulnerability lies in the Mailman/Cgi/private.py file: def true_path(path): "Ensure that the path is safe by removing .." path = path.replace('../', '') path = path.replace('./', '') return path[1:] A crafted URL fragment of the form ".../....///" will pass through the above function and return as "../", thus allowing directory traversal to occur using the following URL syntax to retrieve an arbitrary path. /mailman/private/<list>/<path>?username=<username>&password=<password> Expect vendor advisories nearer the end of the week, for now here is a suggested fix from Barry Warsaw: SLASH = '/' def true_path(path): "Ensure that the path is safe by removing .." parts = [x for x in path.split(SLASH) if x not in ('.', '..')] return SLASH.join(parts)[1:] This issue only affects Mailman installations running on web servers that don't strip extraneous slashes from URLs, such as Apache 1.3.x. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2005-0202 to this mailman issue. Cheers - John _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html

4 6

← Newer
1
...
12
13
14
15
16
17
18
19
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss February 2005