FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 02-12-2009, 04:26 AM
Stan Katz
 
Default Exploit in Upgrade Chain?

I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb 10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen since the lpd exploit of the 1990's. This symptom manifests itself as either a random escalation of the etc directory mode up to 600, or a consistent escalation to mode 600 upon reboot. I don't remember why the lpd exploit did this. If this is an exploit, it shakes my confidence in debian online updating. It would indicate that someone in the trust chain is putting the distribution in jeopardy. Also, the Bastille firewall on the AMD64 began locking down port 80 after about 10min of operation. Adding 80 to all interfaces didn't help. Only shutting down Bastille cleared the block. I fear this is another indication of the exploit. I threw in some iptable rules for some protection, and they have been allowed to stand..so far. Has anyone else experienced this misbehavior after an upgrade? Any suggestions, other than a complete disk wipe on both machines? In any case, where would I go for a trusted rebuild, if there truly is a sabateur in the ranks of the Debian maintainers? Maybe it's time to move to Ubuntu :-(
 
Old 02-12-2009, 01:13 PM
"Boyd Stephen Smith Jr."
 
Default Exploit in Upgrade Chain?

On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:
> I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb
> 10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen
> since the lpd exploit of the 1990's. This symptom manifests itself as
> either a random escalation of the etc directory mode up to 600, or a
> consistent escalation to mode 600 upon reboot.

My /etc is mode 755. Why would that be a problem? Some user/programs may
need to read data out of the directory and root (the owner of my /etc)
certainly needs write permissions.

> I don't remember why the lpd
> exploit did this. If this is an exploit, it shakes my confidence in debian
> online updating.

I don't see how a 600 /etc can be exploited. Do you have any other records
that would indicate you are exploited, or is this just fear-mongering?

> Also, the Bastille firewall on the
> AMD64 began locking down port 80 after about 10min of operation. Adding 80
> to all interfaces didn't help. Only shutting down Bastille cleared the
> block.

Sounds like a bug in Bastille. Can you reproduce reliably? Have you checked
your configuration? If both, has you filed a bug yet?

> I fear this is another indication of the exploit.

How/Why would these be related?

> Has anyone else experienced this misbehavior after an upgrade?

Not here. I've been running Lenny for a number of months.

> Any
> suggestions, other than a complete disk wipe on both machines? In any case,
> where would I go for a trusted rebuild, if there truly is a sabateur in the
> ranks of the Debian maintainers?

I'm forwarding to debian-security; perhaps they will have suggestions. This
topic is more appropriate for that list than debian-user anyway.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 
Old 02-12-2009, 01:32 PM
"Giacomo A. Catenazzi"
 
Default Exploit in Upgrade Chain?

Boyd Stephen Smith Jr. wrote:

On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:

I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb
10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen
since the lpd exploit of the 1990's. This symptom manifests itself as
either a random escalation of the etc directory mode up to 600, or a
consistent escalation to mode 600 upon reboot.


My /etc is mode 755. Why would that be a problem? Some user/programs may
need to read data out of the directory and root (the owner of my /etc)
certainly needs write permissions.



I don't remember why the lpd
exploit did this. If this is an exploit, it shakes my confidence in debian
online updating.


I don't see how a 600 /etc can be exploited. Do you have any other records
that would indicate you are exploited, or is this just fear-mongering?


/etc with 600 is a grave error!
/etc/ must be accessible for the following reasons:
- debian alternatives (and some posix program requires i.e. "editor" command)
- networking: libc need to read some file (resolver, hostname, ...), and this
is done in normal user context
- passwd must be public (indirectly required by POSIX)
- etc has configuration of daemon, which could read such configuration
in different deamon context (not root). This is true especially by
reloading configuration
- and a lot more reasons.

Some files must be protected, not the entire /etc.

ciao
cate


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-12-2009, 07:11 PM
The Well - Systems Administrator
 
Default Exploit in Upgrade Chain?

600 on /etc is technically more secure than the default 755 with normal
POSIX systems, not less. If this is an exploit, it's one that locks
things down tighter than they should normally be. Giacomo is correct
that these incorrect perms can cause other issues, though not security
related ones that I can think of.


Are there a different set of perms you had set on /etc manually? Any
other indication that you've been exploited, or just a hunch based on
circumstantial weirdness based on unexpected /etc privs and bastille?


Best regards,
-Chris

Boyd Stephen Smith Jr. wrote:

On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:


I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb
10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen
since the lpd exploit of the 1990's. This symptom manifests itself as
either a random escalation of the etc directory mode up to 600, or a
consistent escalation to mode 600 upon reboot.



My /etc is mode 755. Why would that be a problem? Some user/programs may
need to read data out of the directory and root (the owner of my /etc)
certainly needs write permissions.




I don't remember why the lpd
exploit did this. If this is an exploit, it shakes my confidence in debian
online updating.



I don't see how a 600 /etc can be exploited. Do you have any other records
that would indicate you are exploited, or is this just fear-mongering?




Also, the Bastille firewall on the
AMD64 began locking down port 80 after about 10min of operation. Adding 80
to all interfaces didn't help. Only shutting down Bastille cleared the
block.



Sounds like a bug in Bastille. Can you reproduce reliably? Have you checked
your configuration? If both, has you filed a bug yet?




I fear this is another indication of the exploit.



How/Why would these be related?



Has anyone else experienced this misbehavior after an upgrade?



Not here. I've been running Lenny for a number of months.



Any
suggestions, other than a complete disk wipe on both machines? In any case,
where would I go for a trusted rebuild, if there truly is a sabateur in the
ranks of the Debian maintainers?



I'm forwarding to debian-security; perhaps they will have suggestions. This
topic is more appropriate for that list than debian-user anyway.




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-13-2009, 12:50 AM
Stan Katz
 
Default Exploit in Upgrade Chain?

When I first experienced "promiscuous" escalation of etc mode from 755 to 600 (at least 8 to 10 years ago) I hunted down a reference by someone that this could happen if the lpd daemon was compromised. I stopped using lpd, and rebuilt my system. That system then worked fine until it was junked.* When both of my current* systems experienced this deja vue, I was quite astounded. Why me? Anyway, I logged into my AMD64 in recovery mode, and began to exit out just about every service script in init.d I felt I could get away without. The mode changing stopped. I then painfully began reenabling scripts, and rebooting, until the mode on etc escalated. Unless this is a very clever exploit, it seems the problem is limited to samba. I haven't had a mode escalation problem, either from reboots, or just power on time since stopping samba on both machines.


Either I'm doing something to cause gross misbehavior in samba, there is a bug in samba, or, taking the path of paranoia, someone along the samba source chain might be a sabateur. I'll start with the first proposition.* My first symptom was the "i have no name" prompts in my xterms when whoami failed. There is a lot of that going on out there on the net, but no one every mentions as a possible cause, an overescalated mode on etc. I'll be ripping my samba out, and replacing it with a surgical install via dpkg from the Debian main site. We'll see....


On Thu, Feb 12, 2009 at 3:11 PM, The Well - Systems Administrator <sysadmin@thewellpoway.org> wrote:

600 on /etc is technically more secure than the default 755 with normal POSIX systems, not less. If this is an exploit, it's one that locks things down tighter than they should normally be. Giacomo is correct that these incorrect perms can cause other issues, though not security related ones that I can think of.




Are there a different set of perms you had set on /etc manually? Any other indication that you've been exploited, or just a hunch based on circumstantial weirdness based on unexpected /etc privs and bastille?



Best regards,

-Chris



Boyd Stephen Smith Jr. wrote:


On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:

*


I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb

10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen

since the lpd exploit of the 1990's. This symptom manifests itself as

either a random escalation of the etc directory mode up to 600, or a

consistent escalation to mode 600 upon reboot.

* *




My /etc is mode 755. *Why would that be a problem? *Some user/programs may need to read data out of the directory and root (the owner of my /etc) certainly needs write permissions.



*


I don't remember why the lpd

exploit did this. If this is an exploit, it shakes my confidence in debian

online updating.

* *




I don't see how a 600 /etc can be exploited. *Do you have any other records that would indicate you are exploited, or is this just fear-mongering?



*


Also, the Bastille firewall on the

AMD64 began locking down port 80 after about 10min of operation. Adding 80

to all interfaces didn't help. Only shutting down Bastille cleared the

block.

* *




Sounds like a bug in Bastille. *Can you reproduce reliably? *Have you checked your configuration? *If both, has you filed a bug yet?



*


I fear this is another indication of the exploit.

* *




How/Why would these be related?



*


Has anyone else experienced this misbehavior after an upgrade?

* *




Not here. *I've been running Lenny for a number of months.



*


Any

suggestions, other than a complete disk wipe on both machines? In any case,

where would I go for a trusted rebuild, if there truly is a sabateur in the

ranks of the Debian maintainers?

* *




I'm forwarding to debian-security; perhaps they will have suggestions. *This topic is more appropriate for that list than debian-user anyway.

*
 
Old 02-13-2009, 03:14 AM
Stan Katz
 
Default Exploit in Upgrade Chain?

Mystery solved. Samba wants to protect smbpasswd with mode 600. User must point Samba to password path. Sample smb.conf that loaded during last lenny upgrade pointed to /etc., not /etc/samba/smbpasswd. Maybe I missed a prompt during the upgrade to fully qualify the path. Maybe there wasn't any?


On Thu, Feb 12, 2009 at 8:50 PM, Stan Katz <stan.katz.hk@gmail.com> wrote:

When I first experienced "promiscuous" escalation of etc mode from 755 to 600 (at least 8 to 10 years ago) I hunted down a reference by someone that this could happen if the lpd daemon was compromised. I stopped using lpd, and rebuilt my system. That system then worked fine until it was junked.* When both of my current* systems experienced this deja vue, I was quite astounded. Why me? Anyway, I logged into my AMD64 in recovery mode, and began to exit out just about every service script in init.d I felt I could get away without. The mode changing stopped. I then painfully began reenabling scripts, and rebooting, until the mode on etc escalated. Unless this is a very clever exploit, it seems the problem is limited to samba. I haven't had a mode escalation problem, either from reboots, or just power on time since stopping samba on both machines.



Either I'm doing something to cause gross misbehavior in samba, there is a bug in samba, or, taking the path of paranoia, someone along the samba source chain might be a sabateur. I'll start with the first proposition.* My first symptom was the "i have no name" prompts in my xterms when whoami failed. There is a lot of that going on out there on the net, but no one every mentions as a possible cause, an overescalated mode on etc. I'll be ripping my samba out, and replacing it with a surgical install via dpkg from the Debian main site. We'll see....



On Thu, Feb 12, 2009 at 3:11 PM, The Well - Systems Administrator <sysadmin@thewellpoway.org> wrote:


600 on /etc is technically more secure than the default 755 with normal POSIX systems, not less. If this is an exploit, it's one that locks things down tighter than they should normally be. Giacomo is correct that these incorrect perms can cause other issues, though not security related ones that I can think of.





Are there a different set of perms you had set on /etc manually? Any other indication that you've been exploited, or just a hunch based on circumstantial weirdness based on unexpected /etc privs and bastille?



Best regards,

-Chris



Boyd Stephen Smith Jr. wrote:


On Wednesday 11 February 2009 23:26:45 Stan Katz wrote:

*


I updated/upgraded both my AMD64 and AMD k6 "Etch" machines between Feb

10-11, 2009 using "Lenny" test. Both picked up a symptom I haven't seen

since the lpd exploit of the 1990's. This symptom manifests itself as

either a random escalation of the etc directory mode up to 600, or a

consistent escalation to mode 600 upon reboot.

* *




My /etc is mode 755. *Why would that be a problem? *Some user/programs may need to read data out of the directory and root (the owner of my /etc) certainly needs write permissions.



*


I don't remember why the lpd

exploit did this. If this is an exploit, it shakes my confidence in debian

online updating.

* *




I don't see how a 600 /etc can be exploited. *Do you have any other records that would indicate you are exploited, or is this just fear-mongering?



*


Also, the Bastille firewall on the

AMD64 began locking down port 80 after about 10min of operation. Adding 80

to all interfaces didn't help. Only shutting down Bastille cleared the

block.

* *




Sounds like a bug in Bastille. *Can you reproduce reliably? *Have you checked your configuration? *If both, has you filed a bug yet?



*


I fear this is another indication of the exploit.

* *




How/Why would these be related?



*


Has anyone else experienced this misbehavior after an upgrade?

* *




Not here. *I've been running Lenny for a number of months.



*


Any

suggestions, other than a complete disk wipe on both machines? In any case,

where would I go for a trusted rebuild, if there truly is a sabateur in the

ranks of the Debian maintainers?

* *




I'm forwarding to debian-security; perhaps they will have suggestions. *This topic is more appropriate for that list than debian-user anyway.

*
 
Old 02-28-2009, 08:46 AM
Arthur Marsh
 
Default Exploit in Upgrade Chain?

Stan Katz wrote, on 13/02/09 14:44:

Mystery solved. Samba wants to protect smbpasswd with mode 600. User must
point Samba to password path. Sample smb.conf that loaded during last lenny
upgrade pointed to /etc., not /etc/samba/smbpasswd. Maybe I missed a prompt
during the upgrade to fully qualify the path. Maybe there wasn't any?


I didn't find this problem listed in the Debian bug tracker or the Samba
bug tracker in a quick search. Did you report or find this problem in
either the Debian or the Samba bug tracker?


If anyone finds a bug like this, it is worth reporting, if only to save
someone else the amount of time that you spent tracking it down.




On Thu, Feb 12, 2009 at 8:50 PM, Stan Katz <stan.katz.hk@gmail.com> wrote:


When I first experienced "promiscuous" escalation of etc mode from 755 to
600 (at least 8 to 10 years ago) I hunted down a reference by someone that
this could happen if the lpd daemon was compromised. I stopped using lpd,
and rebuilt my system. That system then worked fine until it was junked.
When both of my current systems experienced this deja vue, I was quite
astounded. Why me? Anyway, I logged into my AMD64 in recovery mode, and
began to exit out just about every service script in init.d I felt I could
get away without. The mode changing stopped. I then painfully began
reenabling scripts, and rebooting, until the mode on etc escalated. Unless
this is a very clever exploit, it seems the problem is limited to samba. I
haven't had a mode escalation problem, either from reboots, or just power on
time since stopping samba on both machines.

Either I'm doing something to cause gross misbehavior in samba, there is a
bug in samba, or, taking the path of paranoia, someone along the samba
source chain might be a sabateur. I'll start with the first proposition. My
first symptom was the "i have no name" prompts in my xterms when whoami
failed. There is a lot of that going on out there on the net, but no one
every mentions as a possible cause, an overescalated mode on etc. I'll be
ripping my samba out, and replacing it with a surgical install via dpkg from
the Debian main site. We'll see....


Arthur.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org