Re: Potential expoits via application launchers (aka .desktop files)
Hi, On Donnerstag, 12. Februar 2009, Michael S. Gilbert wrote: > I'll wait for lenny to > get out the door rather than submitting these apparently complex and > difficult security (and hence release-critical) issues at the last > minute. Please dont hesitate to file bugs (unless the issue at hand is security related and not public yet, which is not the case here). While it's true that Debian tries to release with 0 RC bugs, it's not the case that a planned release is stopped, "just because" a bug with severity serious or higher pops up. (Because certain bugs can be ignored. If lenny were released today and a RC bug pops up tomorrow, we wont pull back the release neither.) It's also much better to ship with a known and reported bug, than to ship with a bug, which is not reported :) (Because of "we wont hide problems" and because it's generally better to be aware of problems than not.) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: root access on bootup when core-files not found?
Just answered the question myself: The system entered single user mode and that cleary IS wanted behaviour... Sorry for bothering, Simon Simon Campese wrote: > Hello, > > I recently set up a fresh, fully luks-encrypted debian machine (testing > release) with a typo in my crypttab (for a system critical partition) > using the lenny RC2 installer. > After a reboot, the system tries to open the mistyped partition to be > mounted on the critical path (in this case /var) but doesn't succeed. It > then tries to su a maintenance shell (which it can't, as I disabled root > logins), prints an error message (similar to "su failed, root login > disabled") and then nevertheles drops to a root shell (without me entering > a password). > > As I am quite new to Debian, this might be wanted behaviour but common > sense tells me otherwise. I had root access to all mounted partitions so > far without authenticating. > > I currently don't have time to investigate further but nevertheless > thought that this could be of interest. By my understanding this behaviour > should be reproduceable without using luks (by just deliberately placing > an invalid "critical"-mountpoint into fstab or even by deleting a > "critical" system directory and then trying to boot, both with disabled > root-logins). > > > Apologies for this incomplete posting, > > Simon > > > -- > To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
root access on bootup when core-files not found?
Hello, I recently set up a fresh, fully luks-encrypted debian machine (testing release) with a typo in my crypttab (for a system critical partition) using the lenny RC2 installer. After a reboot, the system tries to open the mistyped partition to be mounted on the critical path (in this case /var) but doesn't succeed. It then tries to su a maintenance shell (which it can't, as I disabled root logins), prints an error message (similar to "su failed, root login disabled") and then nevertheles drops to a root shell (without me entering a password). As I am quite new to Debian, this might be wanted behaviour but common sense tells me otherwise. I had root access to all mounted partitions so far without authenticating. I currently don't have time to investigate further but nevertheless thought that this could be of interest. By my understanding this behaviour should be reproduceable without using luks (by just deliberately placing an invalid "critical"-mountpoint into fstab or even by deleting a "critical" system directory and then trying to boot, both with disabled root-logins). Apologies for this incomplete posting, Simon -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Potential expoits via application launchers (aka .desktop files)
A lot of you have probably seen some of the recent coverage about the potential avenue for exploits via kde and gnome application launchers (it looks like xfce is safe, for now) [1],[2],[3]. Is there any plan within debian to begin addressing these concerns? Where do I even start reporting bugs to? Nautilus and dolphin? I'll wait for lenny to get out the door rather than submitting these apparently complex and difficult security (and hence release-critical) issues at the last minute. Regards, Mike [1] http://www.geekzone.co.nz/foobar/6229 [2] http://www.geekzone.co.nz/foobar/6236 [3] http://lwn.net/Articles/178409/ -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Paper on potential security issues with the linux kernel PRNG
I just came across a reference [1] on potential flaws in the linux kernel PRNG (Pseudo-Random Number Generator). Does anyone know if CVE's have been issued for these problems and/or whether they have been fixed either upstream or in debian? If not, someone should issue requests for CVE's. Thanks for any thoughts. Regards, Mike [1] http://eprint.iacr.org/2006/086.pdf -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Exploit in Upgrade Chain?
On Thursday, 2009-02-12 at 12:11:01 -0800, The Well - Systems Administrator 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. Mode 600 will deny /etc to everybody except root while it will change nothing for root. If you have any services on your system that run under non-root UIDs, and that have config under /etc, you hose them with any mode that removes the eXecute bit for "others". So it's not an exploit, it's a Denial of Service. Which I believe *is* security related... Lupe Christoph -- | There is no substitute for bad design except worse design. | | /me | -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Exploit in Upgrade Chain?
On Thu, 12 Feb 2009 15:32:57 +0100 "Giacomo A. Catenazzi" wrote: > Boyd Stephen Smith Jr. wrote: ... > > 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. I'm sure he knows it's an error; his point is just that it's not exploitable. Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 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-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Securing my PC at a Wireless Hotspot?
On Sun, Feb 08, 2009 at 07:56:10PM +1100, Chip Panarchy wrote: > Hello > > You've probably been to a café before that offered WiFi via a Wireless > Hotspot. Or maybe you've been to an airport that had some hotspots? > Well whatever the case, I'm sure you've seen a Public Wireless > Hotspot. Or, at the very least, heard of them. > > So my question to you is, NOT on how to secure the Wireless Hotspot, > but rather on how to secure the connection on my end, to the Hotspot. > > So, how do I secure my PC at a Wireless Hotspot? > > Would there be a way to have 256-bit AES or 256-bit Camellia > encryption on all outgoing traffic? > > Or would you recommend a different method? > > If this is of any use, I will be using the following laptop: Dell > Inspiron 700m. > > Can I please have some recommendations on what I need in order to > secure my connection to the > Wireless Hotspot? > > Thanks in advance, > > Chip D. Panarchy > If you have a secure server to SSH into, you can just use tsocks to forward and SSL-encrypt your traffic. http://pobega.wordpress.com/2009/02/01/tunneling-a-connection-through-ssh/ -- http://pobega.wordpress.com http://identica/pobega signature.asc Description: Digital signature
Re: 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. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
