Re: [SECURITY] [DSA 1336-1] New mozilla-firefox packages fix several vulnerabilities
> CVE-2007-1282 > > It was discovered that an integer overflow in text/enhanced message > parsing allows the execution of arbitrary code. Isn't text/enhanced long forgotten for good? It has never been formally registered, btw, see http://www.iana.org/assignments/media-types/text . I suggest the corresponding handler code should be removed (if the maintainers can persuade their upstreams), to decrease support burden, and the applications be thus falling back to text/plain . VKh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: halted firewalls
> > I'm actually not doing this for the improved security in ithis particular > > case. As this is a home LAN, I don't have tons of room/pc's. So the gateway > > in this case is just another pc, and using this idea I wouldn't have to > > boot this pc for no other reason than "gatewaying". So it's mostly to avoid > > running the gateway, because of the added noise, etc. > > This hack won't help you then. The hardware will still be up and running. It's > just the software thet gets shut down (except for the kernel). > It actually does help on a modern PC where one can spin down an unused hard drive. The fans will still be running, though; throttling down CPU (and further reducing fanning demands) will probably not be a good idea as it will increase the latency added by the hop through the firewall. Good vacuum cleaning / maintenance of the fans that go noisy can help with the fan noise, too. Avoid the temptation to run w/o casing for common external cooling because of the EMR -- you told it's your home. Vassilii -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [meta] Set reply-to to something else?
On Tue, 2005-01-18 at 12:40 +0100, Adrian von Bidder wrote: > Hi, > > With web-board passwords and two or three auto-acks being posted to this > list every week: could we think about setting the Reply-To of I hope that I am not the only one who writes to the auto-ackers and their postmasters that they're using stupid MUAs not honoring Precedence: bulk or Precedence: junk as well as the other list-control fields as a flags to not auto-respond. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doing an ssh into a compromised host
> Meanwhile, the only thing I have is looking at some offline backups and > working remotely in the (compromised) environment. Right now I'm looking at > the lsof output there, a curious entry from Apache shown by lsof: > > apache 3170 root memDEL0,5 0 /SYSV000 > > Does it ring the bell for anyone? (The box runs apache 1.3.26-0woody5). belay that. This looks like the apache scoreboard. A sane apache2 machine has similar entries as well: apache2 1318 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 1926 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 2432 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 2502 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 8538 root mem DEL 0,6 0 /SYSV0c0deb00 apache2 8798 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 27796 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 27797 apache mem DEL 0,6 0 /SYSV0c0deb00 apache2 28306 apache mem DEL 0,6 0 /SYSV0c0deb00 G I'll try to nessus the machine remotely, and see if something boils up from it...
Re: doing an ssh into a compromised host
> You could force the SSH client to *not* forward X11 with -x > (the low-caps x char) regardless other client/server-side > specifications. If you do not specify any other special > forwarding (-L or -R) then there will be no forwarding. Good, that was what I was hoping for. (Obviously, my default /etc/ssh/ssh_config doesn't turn on the fwding by default.) Luckily, I am also not using any agent fwding as well. The box is remote, and I'll only have console access in a couple of days. Meanwhile, the only thing I have is looking at some offline backups and working remotely in the (compromised) environment. Right now I'm looking at the lsof output there, a curious entry from Apache shown by lsof: apache 3170 root memDEL0,5 0 /SYSV000 Does it ring the bell for anyone? (The box runs apache 1.3.26-0woody5). chkrootkit (inside the compromised environment, so it is no big surprise) doesn't report anything. V. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
doing an ssh into a compromised host
I have discovered that one of the machines I have an account on has been hacked. As a result, I am left with the following worries. I have been doing ssh into the box. THe client is set up not to request the X forwarding by the default. When I try "ssh -v" now, I observe no X forwarding being established, whereas "ssh -X -v" does establish X. Question is, could the server have forced an X forwarding on me (w/o my knowledge) having sniffed my local keystrokes? FWIW, I have been doing "ssh-add" and then ssh w/o a need to enter any password during the authentication with the compromised remote host. Thanks for your explanations in advance, Vassilii -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rbl's status?
> Also, for Vassilii - you use the SpamCop blacklists. That is something > that I would be very nervous of. They have some pretty liberal policies > about what they accept, and their automatic tools are not that great at > filtering out innocent parties... > This is why on the primary MX (which I share with some friends) I don't use it at the SMTP level. OTOH, I do use it for my account and I never had a positive hit with it yet. If you have a huge server with a lot of users of various profiles, you probably should only use it for advisory tagging so your users can decide if they want to accept it.
Re: rbl's status?
> Also, for Vassilii - you use the SpamCop blacklists. That is something > that I would be very nervous of. They have some pretty liberal policies > about what they accept, and their automatic tools are not that great at > filtering out innocent parties... > This is why on the primary MX (which I share with some friends) I don't use it at the SMTP level. OTOH, I do use it for my account and I never had a positive hit with it yet. If you have a huge server with a lot of users of various profiles, you probably should only use it for advisory tagging so your users can decide if they want to accept it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rbl's status?
> You do realize that the osirusoft blacklists are defunct and have been > for several months, right? Basing your decision of whether or not to > accept mail from a given host based on an answer from a defunct > blacklist is probably not a good idea. *ouch* thanks. I'm revising my blacklists now, reading http://www.spambouncer.org/ for an up-to-date guideline
Re: rbl's status?
> I just noticed that my exim4 config access to > rbl.mail-abuse.org is no longer valid. I'd heard > Vixie had 'gone pro' but hadn't thought much > about it. I believe it's very old news, smth like 4-5 years or so. > What are the recommended rbl's these days? Best thing is ask on NANAE or exim-users or whatever your favourite MTA is. Here's what I am using here RBL-wise: rbl_domains = bl.spamcop.net/reject : relays.osirusoft.com/reject :spamhaus.relays.osirusoft.com/reject : sbl.spamhaus.org/reject there is a bit of redundancy in my setup as spamhaus is aggregated from 2 places, but it is my secondary MX dedicated box and WTH - it works
Re: rbl's status?
> You do realize that the osirusoft blacklists are defunct and have been > for several months, right? Basing your decision of whether or not to > accept mail from a given host based on an answer from a defunct > blacklist is probably not a good idea. *ouch* thanks. I'm revising my blacklists now, reading http://www.spambouncer.org/ for an up-to-date guideline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rbl's status?
> I just noticed that my exim4 config access to > rbl.mail-abuse.org is no longer valid. I'd heard > Vixie had 'gone pro' but hadn't thought much > about it. I believe it's very old news, smth like 4-5 years or so. > What are the recommended rbl's these days? Best thing is ask on NANAE or exim-users or whatever your favourite MTA is. Here's what I am using here RBL-wise: rbl_domains = bl.spamcop.net/reject : relays.osirusoft.com/reject :spamhaus.relays.osirusoft.com/reject : sbl.spamhaus.org/reject there is a bit of redundancy in my setup as spamhaus is aggregated from 2 places, but it is my secondary MX dedicated box and WTH - it works -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
[snip] > If CR systems get popular then spammers will start replying to the > messages. Most spammers have working email addresses, so it would not be > difficult to automate a response to a CR system. Any CR system which just > requires that you "reply to this email" will be trivially broken by > spammers. [snip] You are right in everything except the tense - it's already happening. I've had friends that use the CR systems reporting that spammers did reply to their challenges. Apparently this is done by the "put your computer to work" victims that spam from their home accounts sometimes even w/o the full understanding of what they're doing. V
Re: Spam fights
[snip] > If CR systems get popular then spammers will start replying to the > messages. Most spammers have working email addresses, so it would not be > difficult to automate a response to a CR system. Any CR system which just > requires that you "reply to this email" will be trivially broken by > spammers. [snip] You are right in everything except the tense - it's already happening. I've had friends that use the CR systems reporting that spammers did reply to their challenges. Apparently this is done by the "put your computer to work" victims that spam from their home accounts sometimes even w/o the full understanding of what they're doing. V -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spam fights
> > For mailing lists this can be achieved by making the list > > subscriber-only. For individual accounts such behaviour is very > > anti-social as it results in confirmation messages being sent in > > response to virus messages. > > Not if the message if refused by the smtp server before it's delivered, > right ? It's not that antisocial to ask the 1% people who aren't > subscribed to subscribe before sending a message. 3 days ago I got blacklisted by outblaze when I got framed by some virus that triggered my majordomo to respond to a forged subscription request with an outblaze's spamtrap "original" address. Luckily, the outblaze postmaster was very quick to respond and whitelist me back. I don't actually know how to prevent this happening in the future. A bit unexpected mode of spamtrap operation, isn't it? V. P.S. maybe we should move the thread to NANAE?
Re: Spam fights
> > For mailing lists this can be achieved by making the list > > subscriber-only. For individual accounts such behaviour is very > > anti-social as it results in confirmation messages being sent in > > response to virus messages. > > Not if the message if refused by the smtp server before it's delivered, > right ? It's not that antisocial to ask the 1% people who aren't > subscribed to subscribe before sending a message. 3 days ago I got blacklisted by outblaze when I got framed by some virus that triggered my majordomo to respond to a forged subscription request with an outblaze's spamtrap "original" address. Luckily, the outblaze postmaster was very quick to respond and whitelist me back. I don't actually know how to prevent this happening in the future. A bit unexpected mode of spamtrap operation, isn't it? V. P.S. maybe we should move the thread to NANAE? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: administrativa: moron autoreply from martin.j@sargas.nl
Lars, if you look at the messages footer, there's a human address (I've put it into CC) of the listmaster to contact if you wish to do such things. It is quite common that the listmaster doesn't look into the list itself for admin requests, esp. if there's one listmaster for a bunch of lists. Vassilii - Original Message - From: "Lars Ellenberg" <[EMAIL PROTECTED]> To: Sent: Thursday, March 27, 2003 8:58 AM Subject: Re: administrativa: moron autoreply from [EMAIL PROTECTED] On Thu, Mar 27, 2003 at 01:36:31PM +0100, Sander Smeenk wrote: > Quoting Lars Ellenberg ([EMAIL PROTECTED]): > > > I got this autoreply on each of my recent posts to the list. > > maybe someone in charge of it can remove this address from the list. > > > Dit e-mail adres bestaat niet > > This is dutch, and translates to 'This email address does not exist'. I know. And thats the reason why I ask the list (administrator) to unsubscribe [EMAIL PROTECTED] otherwise I'd flame that address directly for autoreplying to list posts. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: administrativa: moron autoreply from martin.j@sargas.nl
Lars, if you look at the messages footer, there's a human address (I've put it into CC) of the listmaster to contact if you wish to do such things. It is quite common that the listmaster doesn't look into the list itself for admin requests, esp. if there's one listmaster for a bunch of lists. Vassilii - Original Message - From: "Lars Ellenberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 27, 2003 8:58 AM Subject: Re: administrativa: moron autoreply from [EMAIL PROTECTED] On Thu, Mar 27, 2003 at 01:36:31PM +0100, Sander Smeenk wrote: > Quoting Lars Ellenberg ([EMAIL PROTECTED]): > > > I got this autoreply on each of my recent posts to the list. > > maybe someone in charge of it can remove this address from the list. > > > Dit e-mail adres bestaat niet > > This is dutch, and translates to 'This email address does not exist'. I know. And thats the reason why I ask the list (administrator) to unsubscribe [EMAIL PROTECTED] otherwise I'd flame that address directly for autoreplying to list posts. Lars -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Protection against http tunneling (was: HTTP tunnel with linux server and windows client)
> The question is... is there any way to protect against this? I mean, how > would you differenciate on for example, a squid, the traffic of one of this > tunnels from the real traffic you want to allow? There is a way to protect any particular form of tunnelling (i.e., if you know that a particular tunnel is there, you'll find a way to disrupt it). But there is no practical way to prevent covert communications of an inside user to the outside world, if any reasonable connectivity, through whatever firewall or whatever, exists. You can minimize the risk by monitoring everyone's activity 24hours, but even then you don't have 100% guarantee. And if you close the network, the person can smuggle diskettes in and out, creating a high-latency link. Or use the state of his office lighting (on or off) at every 17th minutes to signify whether the next bit of the message is 0 or 1. Not too good to transmit a picture, but enough to eventually relay a secret encryption key to someone out there watching. You've got the idea...
Re: Protection against http tunneling (was: HTTP tunnel with linux server and windows client)
> The question is... is there any way to protect against this? I mean, how > would you differenciate on for example, a squid, the traffic of one of this > tunnels from the real traffic you want to allow? There is a way to protect any particular form of tunnelling (i.e., if you know that a particular tunnel is there, you'll find a way to disrupt it). But there is no practical way to prevent covert communications of an inside user to the outside world, if any reasonable connectivity, through whatever firewall or whatever, exists. You can minimize the risk by monitoring everyone's activity 24hours, but even then you don't have 100% guarantee. And if you close the network, the person can smuggle diskettes in and out, creating a high-latency link. Or use the state of his office lighting (on or off) at every 17th minutes to signify whether the next bit of the message is 0 or 1. Not too good to transmit a picture, but enough to eventually relay a secret encryption key to someone out there watching. You've got the idea... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd)
(See also the bugs from the CC). I believe that Debian should be somehow put on the CERT vendor list: they give the vendors more advance warning on the security issues before they issue an advisory, allowing to issue an emergency patch. Does anybody on this list (debian-security) have any ties with CERT to do it? - Original Message - From: "Ramon Kagan" <[EMAIL PROTECTED]> To: Sent: Monday, March 03, 2003 4:00 PM Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd) > HI, > > I don't see Debian listed in the notification list at the bottom of the > CERT Advisory. Is there any estimate on the release of patched sendmail > packages? > > Ramon Kagan [snip] > > -- Forwarded message -- > Date: Mon, 3 Mar 2003 13:06:09 -0500 > From: CERT Advisory > To: cert-advisory@cert.org > Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > > > > -BEGIN PGP SIGNED MESSAGE- > > CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > >Original release date: March 3, 2003 >Last revised: -- >Source: CERT/CC > >A complete revision history can be found at the end of this file. > > Systems Affected > > * Sendmail Pro (all versions) > * Sendmail Switch 2.1 prior to 2.1.5 > * Sendmail Switch 2.2 prior to 2.2.5 > * Sendmail Switch 3.0 prior to 3.0.3 > * Sendmail for NT 2.X prior to 2.6.2 > * Sendmail for NT 3.0 prior to 3.0.3 > * Systems running open-source sendmail versions prior to 8.12.8, >including UNIX and Linux systems > [snip] > Appendix A. - Vendor Information > >This appendix contains information provided by vendors for this >advisory. As vendors report new information to the CERT/CC, we will >update this section and note the changes in our revision history. If a >particular vendor is not listed below, we have not received their >comments. > > Apple Computer, Inc. > >Security Update 2003-03-03 is available to fix this issue. Packages >are available for Mac OS X 10.1.5 and Mac OS X 10.2.4. It should be >noted that sendmail is not enabled by default on Mac OS X, so only >those systems which have explicitly enabled it are susceptible to the >vulnerability. All customers of Mac OS X, however, are encouraged to >apply this update to their systems. > > Avaya, Inc. > >Avaya is aware of the vulnerability and is investigating impact. As >new information is available this statement will be updated. > > BSD/OS > >Wind River Systems has created patches for this problem which are >available from the normal locations for each release. The relevant >patches are M500-006 for BSD/OS version 5.0 or the Wind River Platform >for Server Appliances 1.0, M431-002 for BSD/OS 4.3.1, or M420-032 for >BSD/OS 4.2 systems. > > Cisco Systems > >Cisco is investigating this issue. If we determine any of our products >arevulnerablethatinformation will be available at: >http://www.cisco.com/go/psirt > > Cray Inc. > >The code supplied by Cray, Inc. in Unicos, Unicos/mk, and Unicos/mp >may be vulnerable. Cray has opened SPRs 724749 and 724750 to >investigate. > >Cray, Inc. is not vulnerable for the MTA systems. > > Hewlett-Packard Company > >SOURCE: > Hewlett-Packard Company > HP Services > Software Security Response Team > >x-ref: SSRT3469 sendmail > >HP will provide notice of the availability of patches through standard >security bulletin announcements and be available from your normal HP >Services support channel. > > IBM Corporation > >The AIX operating system is vulnerable to the sendmail issues >discussed in releases 4.3.3, 5.1.0 and 5.2.0. > >A temporary patch is available through an efix package which can be >found at >ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z > >IBM will provide the following official fixes: > > APAR number for AIX 4.3.3: IY40500 (available approx. > 03/12/2003) > APAR number for AIX 5.1.0: IY40501 (available approx. > 04/28/2003) > APAR number for AIX 5.2.0: IY40502 (available approx. > 04/28/2003) > > Openwall GNU/*/Linux > >Openwall GNU/*/Linux is not vulnerable. We use Postfix as the MTA, not >sendmail. > > Red Hat Inc. > >Updated sendmail packages that are not vulnerable to this issue are >available for Red Hat Linux, Red Hat Advanced Server, and Red Hat >Advanced Workstation. Red Hat Network users can update their systems >using the 'up2date' tool. > >Red Hat Linux: > > http://rhn.redhat.com/errata/RHSA-2003-073.html > >Red Hat Linux Advanced Server, Advanced Workstation: > > http://rhn.redhat.com/errata/RHSA-2003
Re: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd)
(See also the bugs from the CC). I believe that Debian should be somehow put on the CERT vendor list: they give the vendors more advance warning on the security issues before they issue an advisory, allowing to issue an emergency patch. Does anybody on this list (debian-security) have any ties with CERT to do it? - Original Message - From: "Ramon Kagan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 03, 2003 4:00 PM Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail (fwd) > HI, > > I don't see Debian listed in the notification list at the bottom of the > CERT Advisory. Is there any estimate on the release of patched sendmail > packages? > > Ramon Kagan [snip] > > -- Forwarded message -- > Date: Mon, 3 Mar 2003 13:06:09 -0500 > From: CERT Advisory <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > > > > -BEGIN PGP SIGNED MESSAGE- > > CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail > >Original release date: March 3, 2003 >Last revised: -- >Source: CERT/CC > >A complete revision history can be found at the end of this file. > > Systems Affected > > * Sendmail Pro (all versions) > * Sendmail Switch 2.1 prior to 2.1.5 > * Sendmail Switch 2.2 prior to 2.2.5 > * Sendmail Switch 3.0 prior to 3.0.3 > * Sendmail for NT 2.X prior to 2.6.2 > * Sendmail for NT 3.0 prior to 3.0.3 > * Systems running open-source sendmail versions prior to 8.12.8, >including UNIX and Linux systems > [snip] > Appendix A. - Vendor Information > >This appendix contains information provided by vendors for this >advisory. As vendors report new information to the CERT/CC, we will >update this section and note the changes in our revision history. If a >particular vendor is not listed below, we have not received their >comments. > > Apple Computer, Inc. > >Security Update 2003-03-03 is available to fix this issue. Packages >are available for Mac OS X 10.1.5 and Mac OS X 10.2.4. It should be >noted that sendmail is not enabled by default on Mac OS X, so only >those systems which have explicitly enabled it are susceptible to the >vulnerability. All customers of Mac OS X, however, are encouraged to >apply this update to their systems. > > Avaya, Inc. > >Avaya is aware of the vulnerability and is investigating impact. As >new information is available this statement will be updated. > > BSD/OS > >Wind River Systems has created patches for this problem which are >available from the normal locations for each release. The relevant >patches are M500-006 for BSD/OS version 5.0 or the Wind River Platform >for Server Appliances 1.0, M431-002 for BSD/OS 4.3.1, or M420-032 for >BSD/OS 4.2 systems. > > Cisco Systems > >Cisco is investigating this issue. If we determine any of our products >arevulnerablethatinformation will be available at: >http://www.cisco.com/go/psirt > > Cray Inc. > >The code supplied by Cray, Inc. in Unicos, Unicos/mk, and Unicos/mp >may be vulnerable. Cray has opened SPRs 724749 and 724750 to >investigate. > >Cray, Inc. is not vulnerable for the MTA systems. > > Hewlett-Packard Company > >SOURCE: > Hewlett-Packard Company > HP Services > Software Security Response Team > >x-ref: SSRT3469 sendmail > >HP will provide notice of the availability of patches through standard >security bulletin announcements and be available from your normal HP >Services support channel. > > IBM Corporation > >The AIX operating system is vulnerable to the sendmail issues >discussed in releases 4.3.3, 5.1.0 and 5.2.0. > >A temporary patch is available through an efix package which can be >found at >ftp://ftp.software.ibm.com/aix/efixes/security/sendmail_efix.tar.Z > >IBM will provide the following official fixes: > > APAR number for AIX 4.3.3: IY40500 (available approx. > 03/12/2003) > APAR number for AIX 5.1.0: IY40501 (available approx. > 04/28/2003) > APAR number for AIX 5.2.0: IY40502 (available approx. > 04/28/2003) > > Openwall GNU/*/Linux > >Openwall GNU/*/Linux is not vulnerable. We use Postfix as the MTA, not >sendmail. > > Red Hat Inc. > >Updated sendmail packages that are not vulnerable to this issue are >available for Red Hat Linux, Red Hat Advanced Server, and Red Hat >Advanced Workstation. Red Hat Network users can update their systems >using the 'up2date' tool. > >Red Hat Linux: > > http://rhn.redhat.com/errata/RHSA-2003-073.html > >Red Hat Linux Advanced Server, Advanced Workstation: > > http:
Re: Bug#182886: libc6: local hostnames containing a dot get forwarded outside when doing host-lookups.
> Thanks, I missed that. Being placed unter "internal variables" and > "debug" seems to have tricked me in ignoring this part. > > There should at least be a sentence "search" to indicate that one has > to read the ndots-part to get a real search-path. > > > So it looks like to achieve what you suggest the ndots default > > should be adjusted according to the local policy during the installation > > process, right? > > There is still the problem of an insecure default. Perhaps reassigning > a clone to the installer might be the best solution. > I'm not sure yet if there is any secure default that makes sense for people with just one domain name (majority). Change the debian installer to start educating people about what happens if some.localdomain syntax is used unless ndots is adjusted? Disallow search at all by default, so that even for a local domain one should always give an FQDN, whereas if someone wants the search logic, this should be done via a special config. tool that gives the warnings? Modify all the packages and runtime scripts (like dhcp client stuff) that changes the resolv.conf file to emit a commented warning there as well to educate users that want to change the file manually? v
Re: Bug#182886: libc6: local hostnames containing a dot get forwarded outside when doing host-lookups.
> Thanks, I missed that. Being placed unter "internal variables" and > "debug" seems to have tricked me in ignoring this part. > > There should at least be a sentence "search" to indicate that one has > to read the ndots-part to get a real search-path. > > > So it looks like to achieve what you suggest the ndots default > > should be adjusted according to the local policy during the installation > > process, right? > > There is still the problem of an insecure default. Perhaps reassigning > a clone to the installer might be the best solution. > I'm not sure yet if there is any secure default that makes sense for people with just one domain name (majority). Change the debian installer to start educating people about what happens if some.localdomain syntax is used unless ndots is adjusted? Disallow search at all by default, so that even for a local domain one should always give an FQDN, whereas if someone wants the search logic, this should be done via a special config. tool that gives the warnings? Modify all the packages and runtime scripts (like dhcp client stuff) that changes the resolv.conf file to emit a commented warning there as well to educate users that want to change the file manually? v -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
keysigning and keys maintenance
The D. docs, e.g. the page at http://www.debian.org/events/keysigning , make a lot of effort in making sure the person (Alice's) real identity corresponds to whatever is presented in the key (A) the person is asking another person (Bob) to sign. I think that an additional accent should be placed on what happens with A after Bob signs it, and on what one's signature is worth. Any Bob's signature is worth (for the web of trust) only as much as his least careful signature. Right now there are no ways for a person to say what his minimum requirements for signing someone's key are. Leaving the identity at the signing moment aside (that's pretty well discussed on the existing documents), Bob might consider not to sign the key unless he's sure Alice will keep the path to the A's secret portion trusted, and that Alice will issue a timely revocation if it's compromised. Criteria for the acceptable degree of paranoia of this sort may vary (E.g.: I personally wouldn't sign a key that has it's secret portion accessed from a windows machine full of kazaa/morpheus/... or a machine installed from an old distro with known exploits), but if Bob's consistent, he'll be more or less consistently trusted by various folks. Do you think it's worth a discussion on debian-security, or should I open a wishlist-level bug on the www.debian.org package? gnupg-doc package (the GNU privacy handbook also omits this aspect)? vassilii
keysigning and keys maintenance
The D. docs, e.g. the page at http://www.debian.org/events/keysigning , make a lot of effort in making sure the person (Alice's) real identity corresponds to whatever is presented in the key (A) the person is asking another person (Bob) to sign. I think that an additional accent should be placed on what happens with A after Bob signs it, and on what one's signature is worth. Any Bob's signature is worth (for the web of trust) only as much as his least careful signature. Right now there are no ways for a person to say what his minimum requirements for signing someone's key are. Leaving the identity at the signing moment aside (that's pretty well discussed on the existing documents), Bob might consider not to sign the key unless he's sure Alice will keep the path to the A's secret portion trusted, and that Alice will issue a timely revocation if it's compromised. Criteria for the acceptable degree of paranoia of this sort may vary (E.g.: I personally wouldn't sign a key that has it's secret portion accessed from a windows machine full of kazaa/morpheus/... or a machine installed from an old distro with known exploits), but if Bob's consistent, he'll be more or less consistently trusted by various folks. Do you think it's worth a discussion on debian-security, or should I open a wishlist-level bug on the www.debian.org package? gnupg-doc package (the GNU privacy handbook also omits this aspect)? vassilii -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
