Re: Details on CVE-2016-10229: Remote code execution vulnerability in kernel networking subsystem

2017-04-04 Thread Jan Lühr
Hello,


Am 04/04/2017 um 08:11 AM schrieb Salvatore Bonaccorso:
> Hi
> 
> On Tue, Apr 04, 2017 at 12:52:41AM +0200, Jan Lühr wrote:
>> Hei folks,
>>
>> android recently patched CVE-2016-10229: Remote code execution
>> vulnerability in kernel networking subsystem.
>>
>> Since https://security-tracker.debian.org/tracker/CVE-2016-10229 is
>> rather blank ... does this problem exists in debian, too?
> 
> The problem has been fixed in Debian stable already with
> 3.16.7-ckt20-1+deb8u2. I have updated the tracker. Unfortunately that
> is one of the CVE assigned by Android and assigned only later on. I
> guess most distributions have the fixes already in their releases
> (without CVE references).

Thanks!

Greetz, Jan

-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



Details on CVE-2016-10229: Remote code execution vulnerability in kernel networking subsystem

2017-04-03 Thread Jan Lühr
Hei folks,

android recently patched CVE-2016-10229: Remote code execution
vulnerability in kernel networking subsystem.

Since https://security-tracker.debian.org/tracker/CVE-2016-10229 is
rather blank ... does this problem exists in debian, too?

Thanks, Jan
-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



signature.asc
Description: OpenPGP digital signature


Re: CVE-2016-7117 Remote code execution vulnerability in kernel networking subsystem

2016-10-05 Thread Jan Lühr
Hello,


Am 10/05/2016 um 06:52 AM schrieb Salvatore Bonaccorso:
> On Tue, Oct 04, 2016 at 11:54:12PM +0200, Jan Lühr wrote:
>> Hello,
>> Am 10/04/2016 um 07:57 PM schrieb Nicholas Luedtke:
>>> On 10/04/2016 11:40 AM, Felix Knecht wrote:
>>>
>>>> On 10/04/2016 06:38 PM, Jan Lühr wrote:
>>>>> CVE-2016-7117 was patched in Android today.I don't see much information
>>>>> right now. The title is rather frightening - the issue appears to be 
>>>>> urgent.
>>>> The following upstream kernel commit is referenced in the security 
>>>> bulletin:
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d
>>>>
>>>> No idea if this is fixed in Debian though.
>>>>
>>>> Felix
>>>>
>>> Looks like it was picked up when Debian rolled to 3.16.36-1.
> I updated the security-tracker information for CVE-2016-7117:
> 
> https://security-tracker.debian.org/tracker/CVE-2016-7117 . The fix is
> as well included in 3.16.36-1.

Thanks for the info!
Updating dsa-3659 may help confused people like me ;-).

Greetz,
yanosz

-- 
-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



signature.asc
Description: OpenPGP digital signature


Re: CVE-2016-7117 Remote code execution vulnerability in kernel networking subsystem

2016-10-04 Thread Jan Lühr
Hello,
Am 10/04/2016 um 07:57 PM schrieb Nicholas Luedtke:
> On 10/04/2016 11:40 AM, Felix Knecht wrote:
> 
>> On 10/04/2016 06:38 PM, Jan Lühr wrote:
>>> CVE-2016-7117 was patched in Android today.I don't see much information
>>> right now. The title is rather frightening - the issue appears to be urgent.
>> The following upstream kernel commit is referenced in the security bulletin:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34b88a68f26a75e4fded796f1a49c40f82234b7d
>>
>> No idea if this is fixed in Debian though.
>>
>> Felix
>>
> Looks like it was picked up when Debian rolled to 3.16.36-1.

Thanks for the info - if Felix is right, then 4.7 (jessie backports) is
secure, since it was released months after the fix was pushed to the
mainline kernel.

However, it's somewhat strange that a bug labeled "Linux Kernel
Use-After-Free Remote Code Execution Vulnerability", concerning a lot of
kernels released in the last years
(http://www.securityfocus.com/bid/93304) seem to be fixed in android
only. Do you know any details?

Anyway, using jessie-backports seem to help, thus I'm going for it...

Thanks,
Greetz, Jan
-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



signature.asc
Description: OpenPGP digital signature


CVE-2016-7117 Remote code execution vulnerability in kernel networking subsystem

2016-10-04 Thread Jan Lühr
Hello,

CVE-2016-7117 was patched in Android today.I don't see much information
right now. The title is rather frightening - the issue appears to be urgent.

Can you confirm, that common Debian installation are unaffected and
cannot be taken over via CVE-2016-7117?
If not, I'd like to shut down a few boxes, unless there's a patch or
work-around.

Greetz,
yanosz
-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



signature.asc
Description: OpenPGP digital signature


CVE-2016-1503 / Debian Bug 810621

2016-04-06 Thread Jan Lühr
Hello folks,

Google patched CVE-2016-1503 in Android recently. Debian Bug #810621 is
open since January 2016 - an upstream fix seems to be available since
Tuesday (Debian BTS says so).
Info: https://security-tracker.debian.org/tracker/CVE-2016-1503

Will there be a DSA?

Thanks,
Jan



Re: [SECURITY] [DSA 3481-1] glibc security update

2016-02-17 Thread Jan Lühr
Hello folks,

thanks for providing a patch in Debian. One question:

Am 02/16/2016 um 03:18 PM schrieb Salvatore Bonaccorso:

> CVE-2015-7547
> 
> The Google Security Team and Red Hat discovered that the glibc

Comparing the age (2015-07) and the severity: Can you give some details
on the situation? Why was the bug fixed so late?

Which parties influenced the release date?
Are you aware of exploiting by APT-Groups or nation state actors?

Thanks,
Jan

-- 
There's a ripped off cord
To my TV screen
With a note saying:
"Im not afraid to dream"
-- Donkey Boy, Crazy Something Normal



signature.asc
Description: OpenPGP digital signature


cmrekey.adv ?

2013-11-16 Thread Jan Lühr
Hello folks,

short one: Is Debian GNU/Linux affected by 
http://www.openssh.com/txt/gcmrekey.adv ?

Thanks,
Keep smiling
yanosz


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [volatile] Updated clamav-related packages available fortesting

2010-04-18 Thread Jan Lühr
Hello,

On Sunday 18 April 2010 22:52:41 Jan Lühr wrote:
> Hello,
>
> On Friday 16 April 2010 10:01:46 you wrote:
> > Hi,
> >
> > Jason Self wrote/schrieb @ 15.04.2010 21:52:
> > > Kurt Roeckx  wrote ..
> > >
> > >> What does this mean exactly?
> >
> > deb http://volatile.debian.org/debian-volatile \
> > lenny-proposed-updates/volatile main contrib non-free
>
> The imho more interesting point is: What does it mean in the long term?
> The current situation is:
> Volatile has clamav 0.95, while upstream has 0.96.  There are security
> related issues in 0.95 (DoS etc.?) [1] that might affect(?) volatile -

> [1]
> http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob_plain;f=ChangeLog;hb
>=clamav-0.95.3 [2] http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/

sorry, [1] was meant to be 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577462

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201004182305.36598.debian-secur...@stephan.homeunix.net



Re: [volatile] Updated clamav-related packages available fortesting

2010-04-18 Thread Jan Lühr
Hello,

On Friday 16 April 2010 10:01:46 you wrote:
> Hi,
>
> Jason Self wrote/schrieb @ 15.04.2010 21:52:
> > Kurt Roeckx  wrote ..
> >
> >> What does this mean exactly?

> deb http://volatile.debian.org/debian-volatile \
> lenny-proposed-updates/volatile main contrib non-free

The imho more interesting point is: What does it mean in the long term?
The current situation is: 
Volatile has clamav 0.95, while upstream has 0.96.  There are security related 
issues in 0.95 (DoS etc.?) [1] that might affect(?) volatile - futhermore the 
clamav-people are suggesting to use the latest version [2] - that is 0.96.
Volatile itself is not supported by the security team [3] and the security 
team refuses the support the current stable version [4].

As a sysop running lenny/clamav on a few hosts, I started building clamav from 
source and reading clamav's announce list.
But I wonder, what does it mean in the long run:
- Will volatile be updated to 0.96 soon?
- Will clamav (in volatile) receive official security support?
- Are there any (better supported) alternatives to clamav in lenny?
- Afair there is no specific EOL-/Kill-Switch in clamav: ClamAV <= 0.94 is 
unable to handle "big" incremental updates and a "too" big update was 
shipped. Is it - from a naive point of view - just a bug that can be fixed in 
debian [5]? Just apply the given patch [6] in lenny's clamav and be 
happy? ;-)

Thanks,
Keep smiling
yanosz



[1] 
http://git.clamav.net/gitweb?p=clamav-devel.git;a=blob_plain;f=ChangeLog;hb=clamav-0.95.3
[2] http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/
[3] http://www.debian.org/volatile/index.en.html
[4] http://lists.debian.org/debian-security-announce/2009/msg00228.html
[5] https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1395
[6] https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1395#c12


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/201004182252.41966.debian-secur...@stephan.homeunix.net



Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

2005-07-14 Thread Jan Lühr
Greetings,

Am Donnerstag, 14. Juli 2005 17:40 schrieb Herwig Wittmann:
> Hi!
>
> I am trying to understand if my organization can rely on the debian
> security announcement mailing list as only source of security alerts in
> the future.
>
> This would be very convenient- but the delay that seems to have passed
> between the original squirrelmail security announcement and the time I
> received the alert via [EMAIL PROTECTED] is worrying:

If you've been following debian for at least a couple of months, you got to 
know, that this issue was fixed rather fast.
However, my - one and only - advice in this case is: Don't use debian 
packages, if this is vital for you!

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Debian Security Support in Place

2005-07-09 Thread Jan Lühr
(open letter to the debian security team)
Greetings,..

on friday, 8th july 2005 07:58 Martin Schulze wrote:

[...]
> The Debian project confirms that the security infrastructure for both
> the current release Debian GNU/Linux 3.1 (alias sarge) and the former
> release 3.0 (alias woody) is working again.  The security team is now
> able to provide updates on a regular basis again.
[...]
> There were several issues with the security infrastructure after the
> release of sarge, that lead to the Debian security team being unable
> to issue updates to vulnerable packages.  These issues have been fully
> resolved, and the infrastructure is working correctly again.

Nice to hear, thanks to all. You obviously spent a lot of time and efforts in 
restoring  debian security. Thanks.

But maybe, some rather constructive critism is required as well- and
ehm, well, to be honest, imho this is not satisfying:

It has never been official announced, that the security infrastructure is not 
working. It is quite confusing, that you report the end of problems you 
haven't reported at first, furthermore if the end of this problem justifies 
an official debian announce, the beginning of this problem should have been 
announced to.
Knowing a security problem is imho probably more important than knowing not 
having a problem, because, a security problem requires defensive actions.

Another point is the explanation.
"several issues with the security infrastructure" can probably mean anything. 
From failing power supplying units up to conflicts within the security team.
By that the explanation is not satisfying, too.

There has been a few rumours in joey's blog, but anyway, I'm missing official 
statements / announces, why this had happend (technically and 
non-technically) how it was solved, and how it is prevent in the future - and 
I guess,  others are missing 'em as well.

Looking back to the break-in 2003, this issue was handled very good and 
transparent. Imho this was a good example how things can be handled -
thus going on that way ought to be quite better.

Thanks for your patience,
Keep smiling
yanosz



Re: Question about Debian security policy

2005-06-30 Thread Jan Lühr
Greetings,

Am Donnerstag, 30. Juni 2005 12:57 schrieb Paul Haesler:
> > Hi everybody. I hope this question won't be too stupid.
> > When I perform a standard installation (i.e minimal), the installer
> > installs many servers, and launches them (like portmap, ssh, exim,
> > etc). Why? I think that OpenBSD and FreeBSD, for example, don't launch
> > any daemon at all, or at least prompt you before doing that. There
> > must be a reason, but I don't see it (I'm not a networking/security
> > guru, so please forgive me if the answer is obvious).
>
> I think you'll find OpenBSD launches at least sshd and sendmail
> in the default install (although sendmail only listens on
> loopback interface by default).  I've always wondered about
> portmap in debian myself - I presume it's to do with NFS. Perhaps
> it has to be part of the base system to support network installs.

When I last installed OpenBSD I was asked on whether I want so use ssh. It 
doesn't start automatically.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Bad press related to (missing) Debian security

2005-06-27 Thread Jan Lühr
Greetings,

Am Montag, 27. Juni 2005 20:10 schrieb Adam Majer:
> Jan Lühr wrote:
> >Greetings,
> >
> >Am Montag, 27. Juni 2005 15:54 schrieb Carl-Eric Menzel:
> >>Does anybody know what the actual problem is, i.e. why there are no
> >>updates?
> >
> >This is not an "actual" problem, this problem is rather imho structual. In
> >it's last one to two years Woody was starving out of security updates.
> >(Samba, Mozilla, Kernel, etc.).
>
> These are much less of a problem since they deal with either Intranet
> only applications (Samba), client side applications (mozilla) or the
> kernel that one usually rolls their own for their servers. What I really
> care about from Debian security team is up-to-date fixes for server
> applications that can be exposed to the Internet. For example, apache,
> squid, spamassassin, postfix, sendmail, exim, etc...

I'm not refering to exploits / bugs in general. I'm refering to the 
patch-port-situation in Debian.

Keep smiling
yanosz



Re: Bad press related to (missing) Debian security

2005-06-27 Thread Jan Lühr
Greetings,

Am Montag, 27. Juni 2005 15:54 schrieb Carl-Eric Menzel:
> On Mon, 27 Jun 2005 15:50:19 +0200, "Jan Wagner" <[EMAIL PROTECTED]> said:
> > On Monday 27 June 2005 15:25, W. Borgert wrote:
> > > Just FYI: The well-known German Heise Newsticker (IT related) has an
> > > article today with the title "Debian without security update for
> > > several weeks": http://www.heise.de/newsticker/meldung/61076
> > > Hm, bad reputation for us...
> >
> > This was only a question of time .. :(
>
> Does anybody know what the actual problem is, i.e. why there are no
> updates?

This is not an "actual" problem, this problem is rather imho structual. In 
it's last one to two years Woody was starving out of security updates. 
(Samba, Mozilla, Kernel, etc.). 

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: SpamAssassin DOS-Fix anytime soon ?

2005-06-25 Thread Jan Lühr
Greetings,...

Am Freitag, 24. Juni 2005 15:58 schrieb Marek Olejniczak:
> On Fri, 24 Jun 2005, Nicolas [iso-8859-1] François wrote:
> > On Thu, Jun 23, 2005 at 03:52:14PM +0200, Marek Olejniczak wrote:
> >> There is also a bug in su package which is since 6 days not fixed.
> >> Hallo, security team, wake up! Debian Sarge is buggy! Sarge is
> >> dangerous.

Come down, this is
- local
- I already privileged user is needed.

Spamassin is remote and commercial relevant. (!)

However, does anybody know, how this issue is handled in FreeBSD?

Keep smiling
yanosz



Re: SpamAssassin DOS-Fix anytime soon ?

2005-06-23 Thread Jan Lühr
Greetings,..

Am Donnerstag, 23. Juni 2005 13:42 schrieb [EMAIL PROTECTED]:
> Hi list,
>
> a remote-dos-vulnerability in spamassassin 3.0.1-3.0.3 was announced a
> week ago. while most other distributions have since then reacted on this
>   a debian stable security fix seems still unavailable. on the package
> maintainer's page it says the fix is long done and is just waiting for
> the security-team to act on it [0].
>
> so my question is: why has the fix not been released yet (after 7 days)?
> after all, a remotely exploitable bug in most mailreceiving systems
> should have a rather high priority.

There is no reason to create a third threat for that issue.
If you wanna have a secure Linux port dist the package by yourself or use 
SuSE. They fixed it already.

fup2 previous threads.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Security Support by the Security-Team

2005-06-19 Thread Jan Lühr
Greetings,

Am Samstag, 18. Juni 2005 09:04 schrieb Helmut Toplitzer:
> Hi!
>
> Just a few remarks:
>
> << Use unstable or testing, and apply security fixes yourself.  Over
>
> To my opinion this is a bad suggestion. Maybe my last mail was a bit
> unclear about this. As security is a process rather than a state,
> your systems will hardly ever have all the available security-patches.
> (Not to note that it's not possible to keep up with this job
> if you are alone with it, which will be the fact if you do it by
> hand for testing/unstable.)

Well, not necessary, security, as done - is a process and and a state. You do 
either configure your deamons to run less-privilged chroot'ed or you don't. 
This is no process in this.

> So the question is how to deal with this. As every distribution has
> a security-team these days 

Not every...

> (or at least should have) it is possible 
> to get the security-patches in (quite short) time. 

Well. what is a "short time" here?

> They established a 
> processes how these patches get into the distributions and do a lot
> of communication with each other that none is missed.

At least we hope.

> (And if you ever tried to, you will know that this is a quite complex
> job to do if you want to do it well.)

Of course, at least consider the amount of packages.

> As result a lot of people rely on the work of these teams.
> Especially Debian has a very "open" way to do this. 

This is wrong, (more or less). Debian has access to non-disclosed information.
If you interpret the d-s-c in a strict way, it is not allowed, too - but AFAIK 
this has never been a big issue (?) (However this is quite difficult to 
discuss, 'cause full- vs. non disclosure is not settled at all)

> Security 
> problems a handled publicly if there's no request to do it not
> this way.

No.

> So if you protect your systems (more than 2) by these updates, you would
> be well advised to establish a process yourself how you get them onto
> your system and how - in general - you keep them more or less secure.

No. The truth is (at the moment and in the near past), that you have to 
backport the patches by yourself - But  Debian offers a framework for 
porting.

> And the information if Debian-Security is
> working as expected is a very valuable one to people who did this.

How do you define "expected" ? Debian security is not a just-in-time-patch 
delivery service working 24/7. 
Imho Debian security is a instance allowing patches to get into stable. So if 
you set up stable years after it's release, it is realistic to assume, that 
no vuln older than a couple of months/ weeks is included (if a patch is 
available). (Well, they were some, even in essential packages, but you'll 
know them if you follow this list)

> Hopefully my considerations are clear now. (This mail became much
> longer than I wanted.)

Your consideration are quite clear, but imho you expect to much.
I decided to stop moaning and  criticizing  because

- I cannot do better
- I don't pay them - they are volunteers
- I don't have to use their services
- I said a lot, I triggered some processes I don't like to have happened
- I bashed on the wrong guys.
  
Keep smiling
yanosz 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Security Support by the Security-Team

2005-06-17 Thread Jan Lühr
Greetings,

Am Freitag, 17. Juni 2005 10:58 schrieb Florian Weimer:
> Rumors suggest that the technical foundations of security support for
> sarge and woody are working again.

Nice to hear - however, a SpamAssassin-patch has to be ported to sarge.[1] 
Let's see... the Sec-Announce was posted ~2 days ago. I expect exploits to 
appear soon, considering the uhm, eh... "commercial interest" in delivering 
spam.

Everyone is to invited, to count the number of days...

Keep smiling
yanosz

[1] 
http://marc.theaimsgroup.com/?l=spamassassin-announce&m=111886630726077&w=2


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Well - and kernel 2.4.18?

2005-04-03 Thread Jan Lühr
Greetings,

Am Sonntag 03 April 2005 23:16 schrieb Jan LÃhr:
> Greetings,
>
> Am Sonntag 03 April 2005 22:57 schrieb Harald Krammer:
> > Hi Jan,
> > I had the same question but this is a while ago.  At the moment I use
> > kernel 2.4.27 from backport.org.
> >
> > Here is the link from the old thread:
> > http://lists.debian.org/debian-security/2005/01/threads.html#00201
>
> Me, too ;)
> However, I gave you some *explanation" that time ;-)
> However,
> Btw. I'm quite worried about the Shape of Debian's security.
> Take   CAN-2004-1154 "[SECURITY] [DSA 701-1] New samba packages fix
> arbitrary code execution" for instance.
> Fixed in Samba: 15th December 2004 (with 3.0.10 from samba.org)
> Fixed in SuSE:  22th December 2004
> Fixed in Woody: 31st. March 2005
>
> That ain't good.

Furthermore - it might be in important issue:

Is Samba going to be the next mozilla?
The Sama 2.2 tree is obsolete and not provided with upstream fixes.[1]
The recently fixed issue, may be harmful. (Although I haven't seen any public 
exploits yet). On securityfocus it is characterized as  possible _remote_ 
_root_ exploit.
"An attacker with access to an SMB share may leverage this issue to overwrite 
the heap of the affected process, facilitating code execution with superuser 
privileges." [1]
Imho, this ain't very serios - but noticeable serious, 'cause 2004-1154 is the 
one and only listed "common bug" for 3.0.10 and apart of two minor changes 
3.0.10 is a bugfix-release for 1154 [3]).

Furthermore, Sarge is not freezed yet, thus praising the lord for not coming 
up any samba exploits 'till Sarge releases is foolish in my opinion.

So what will Debian do? 
Samba is an integral part of many Debian servers out there...

Keep smiling
yanosz

[1] http://us1.samba.org/samba/history/samba-2.2.12.html
[2] http://www.securityfocus.com/bid/11973/discussion/
[3] http://us1.samba.org/samba/history/samba-3.0.13.html



Re: Well - and kernel 2.4.18?

2005-04-03 Thread Jan Lühr
Greetings,

Am Sonntag 03 April 2005 22:57 schrieb Harald Krammer:
> Hi Jan,
> I had the same question but this is a while ago.  At the moment I use
> kernel 2.4.27 from backport.org.
>
> Here is the link from the old thread:
> http://lists.debian.org/debian-security/2005/01/threads.html#00201

Me, too ;)
However, I gave you some *explanation" that time ;-)
However,
Btw. I'm quite worried about the Shape of Debian's security.
Take   CAN-2004-1154 "[SECURITY] [DSA 701-1] New samba packages fix arbitrary 
code execution" for instance.
Fixed in Samba: 15th December 2004 (with 3.0.10 from samba.org) 
Fixed in SuSE:  22th December 2004 
Fixed in Woody: 31st. March 2005

That ain't good.

Keep smiling
yanosz

 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Well - and kernel 2.4.18?

2005-04-03 Thread Jan Lühr
Greetings,

is there any progress in providing fixed kernels for stable?
I was just wondering 'cause I expected 'em three months ago.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Kernel security advice

2005-02-18 Thread Jan Lühr
Greetings,

Am Freitag, 18. Februar 2005 04:51 schrieb JM:
> Hello,
>
> * Besides grsecurity patch, pax etc...What other recommendations are there
> to patch a kernel on a woody or sarge production server?
>
> * Any experiences/opinions with the debian-hardened kernels?
>
> * Is it that terrible running X if access is not allowed from the network,
> only locally?

I recently had some trouble with pax (gresecurity) and java (sun). Thus if you 
use tomcat etc., pax won't be an option.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Grsecurity patches on Debian

2005-02-07 Thread Jan Lühr
Greetings,..

Am Montag, 7. Februar 2005 14:10 schrieb Andras Got:
> Hi,
>
> You should start with grsec low and proc restricions set customly.
> Hardening your kernel is always a option. The grsec default high settings,
> and PaX break Jetty (java server container) in two, so it simply won't
> start, gradm won't help as I know. After the grsec default low settings you
> should read about the functions grsec has, and consider which one is good
> for you or worth using. I have grsec deafult high (+ the new extras set)
> kernels on gateways and one prod webserver. It works very well so far.
> Grsec+PaX itself won't break any program, that don't do anything wierd or
> unusual and suspicous. When you use chroot (postfix uses it by default),
> grsec can harden very vell your chroot systems.

Well, once I had some trouble using wine on an openwall patched terminal 
server.
I don't know, whetere these issue still apply.

Keep smiling
yanosz
-- 
Achtung: Die E-Mail-Adresse [EMAIL PROTECTED] wird in Kürze 
deaktiviert werden. Bitte nutzen Sie die Adresse
[EMAIL PROTECTED]



Re: [OT] tales (was: woody kernel image)

2005-01-30 Thread Jan Lühr
Greetings,

Am Sonntag, 30. Januar 2005 21:14 schrieb Alexander Schmehl:
> Hi!
>
> * Michelle Konzack <[EMAIL PROTECTED]> [050130 20:29]:
> > > how does it come, that every time, you're telling such a story and are
> > > requested for some proof, one of your services is down, you cite
> > > completly unrelated URLs or you don't answer at all?
> >
> > Why not go to  and search for it ?
>
> May I add this as an other case of "MK makes statements which she can't
> proofe" to my list?  Making a statement, and telling others to proof it
> for themself doesn't make your argument look very good.
>
> But anyway, I'm subscribed to both lists, and all I can say is:
>
> Been there, done that, got no shirt.
>
> So until I'm showed otherwise, I'm convident, that there is no mail to
> debian-devel or debian-kernel, stating that support for the 2.4.18*
> kernels in the current stable release has been dropped.
>
> And beside that, Joeys, forwarded to this list by Jan Minar a couple of
> hours ago (id: <[EMAIL PROTECTED]>)
> proofes, that you are wrong.

Don't take it down personal. Jugding about DSA's I've seen, there is currently 
_no_ security-support for 2.4.18. For reasons I don't know, for thinks, I 
don't understand, important patches seem to be missing.
If you have information about the status of sec-sup in 2.4.18 please let us 
know.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [Fwd: security]

2005-01-29 Thread Jan Lühr
Greetings,...

Am Samstag, 29. Januar 2005 16:05 schrieb michael:
> On debian-user it was suggested I also post this here, thanks, Michael
>  Forwarded Message 
> From: michael <[EMAIL PROTECTED]>
> To: debian user 
> Subject: security
> Date: Fri, 28 Jan 2005 09:46:31 +
> I notice that frequently many machines around here get attacked by a
> potential hacker (a prog I guess) trying lots of usernames to get in to
> all the machines, using the same set of usernames at the same time. Have
> people seen this on their machines? I'm guessing it's a virus/worm on a
> Windows box doing this but does anybody know more?
>
> I've followed & done most of the suggestions listed in chpts 4 & 5 of
> "Securing Debian" HowTo/Manual although I will admit to not following
> and therefore not having got around to firewalling. Other suggestions
> most welcome.

Yesterday's news. Don't use standard password combos and they won't harm you.

Keep smiling
yanost


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: woody kernel image

2005-01-29 Thread Jan Lühr
Greetings,

Am Freitag, 28. Januar 2005 21:25 schrieb Harald Krammer:
> hi !
>
> I have running some debian/woody machines with kernel 2.4.18.
>
> @:~$ cat /proc/version
> Linux version 2.4.18-1-k7 ([EMAIL PROTECTED]) (gcc version 2.95.4 20011002
> (Debian prerelease)) #1 Wed Apr 14 19:20:42 UTC 2004
>
> I saw the last security fix was DSA-479-1 ( long ago) - is it better to
> switch to 2.4.29 or exits new kernels with all security pachtes ?

Kernel 2.4.18 seems to have left the planet due to extraterrestrial 
commitments. Please use sid's kernel packages instead.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release

2005-01-12 Thread Jan Lühr
Greetings,

Am Mittwoch, 12. Januar 2005 18:27 schrieb Sam Morris:
> Jan LÃhr wrote:
> > Greetings,
> >
> > things seem to be in a rush right now, and I'm looking for a little
> > overview. In the past 1-2 months several kernel exploits rushed through
> > the news that might / can / probably will affect debian stable. However,
> > I haven't seen any signle DSA regarding the following issues: Can you
> > please give me an overview:  Which problems do affected
> > kernel-source-2,4.18? - If so, what is the current status of the
> > according DSA? Because of running an
> > terminal-Server I'd like to know, what's going on at these issues.
>
> Add CAN-2004-0554 as well--bug #261521 has been open against
> kernel-image-2.4.18-1-i386 (but not against kernel-image-2.4.18-i386)
> since July wish no updates.

Uhoh. I tend to use 4-letter words, but this would be highly inappropriate. If 
it's true, can someone from the official security / kernel team post an 
official statement on this issue, please?
It was scared, when I saw a CAN Id from 1999 in 2004 when a squid bug was 
fixed, but this quite serious.
But anyway, it's not my point to critize the work of the teams. I don't know 
how to fix it, I don't the reasons for not fixing it already.
@who-ever-is-in-charge-with this. Please state your reasons and give a view on 
comming DSAs.
   
> I believe someone posted here a few months ago asking about the bug, and
> was told that updates were being prepared--but that has not yet happened.
> :(

Release Sarge! - and I will switch to testing using the freebsd kernel. 
Hopefully, things are not that mad then :-(

keep smiling
yanosz



CAN-2005-0001, CAN-2004-1235, CAN-2004-1137, CAN-2004-1016, Georgi Guninski security advisory #72, 2004, grsecurity 2.1.0 release

2005-01-12 Thread Jan Lühr
Greetings,

things seem to be in a rush right now, and I'm looking for a little overview.
In the past 1-2 months several kernel exploits rushed through the news that 
might / can / probably will affect debian stable. However, I haven't seen any 
signle DSA regarding the following issues: Can you please give me an 
overview:  Which problems do affected kernel-source-2,4.18? - If so, what is 
the current status of the according DSA? Because of running an 
terminal-Server I'd like to know, what's going on at these issues.


Thanks in advance, Keep smiling
yanosz

CAN-2005-0001 "Linux kernel i386 SMP page fault handler privilege escalation": 
http://www.isec.pl/vulnerabilities/isec-0022-pagefault.txt (I'm not runnig 
SMP ;)
CAN-2004-1235 "Linux kernel uselib() privilege elevation" 
http://isec.pl/vulnerabilities/isec-0021-uselib.txt (Sounds scary PoC Code is 
included, seems to be discussed here)
CAN-2004-1137 "Linux kernel IGMP vulnerabilities" (Sounds really scary. Are we 
effected? Debian Woody seems to be uneffected, but what about sarge / sid?)
http://isec.pl/vulnerabilities/isec-0018-igmp.txt
CAN-2004-1016 "Linux kernel scm_send local DoS"
 http://isec.pl/vulnerabilities/isec-0019-scm.txt
Georgi Guninski security advisory #72, 2004 "Fun with the linux kernel 
(2.6,2.4)"
http://www.guninski.com/where_do_you_want_billg_to_go_today_2.html
grsecurity 2.1.0
 http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2005-01/0070.html
gives on scary / FUD-ish view on the linux kernel. Without discussing their 
thesis in detail, are patches available? Is kernel-source-2.4.18 affected?







-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Fwd: dhcp-2 Security Announcement

2004-11-09 Thread Jan Lühr
Greetings,

just asking, cause it is relevant for me:
Will there be new official stable packages in the next few days (3-4)?
(If not, I've to patch it by myself)

Keep smiling
yanosz
--- Begin Message ---
  *** From dhcp-announce -- To unsubscribe, see the end of this message. ***

Debian has recently distributed a security advisory on the dhcp-2.0pl5
package they distribute.  You can read about that here:

http://www.debian.org/security/2004/dsa-584

The following versions of ISC DHCP are vulnerable:

dhcp-2.0:  All versions are vulnerable.
dhcp-3.0:  dhcp-3.0b1pl17 and previous versions are vulnerable.

All users of these versions should upgrade to the latest dhcp-3
release, currently dhcp-3.0.1.


Note: If for some reason upgrading from dhcp-2 is not possible, you
may also consider applying this patch:

ftp://ftp.isc.org/isc/dhcp/dhcp-2.0-history/dhcp-2.0pl6.patch
ftp://ftp.isc.org/isc/dhcp/dhcp-2.0-history/dhcp-2.0pl6.patch.asc

But users are strongly advised to make the upgrade to dhcp-3 now.

-- 
David W. Hankins"If you don't do it right the first time,
Operations Engineer you'll just have to do it again."
Internet Systems Consortium, Inc.   -- Jack T. Hankins
---
To unsubscribe from this list, visit http://www.isc.org/dhcp-lists.html
or send mail to [EMAIL PROTECTED] with the subject line of
'unsubscribe'.
---

--- End Message ---


Re: Security issue? Daemon users has to much rights...

2004-10-24 Thread Jan Lühr
Greetings,...

Am Samstag, 23. Oktober 2004 05:58 schrieb Daniel Pittman:
> On 23 Oct 2004, Jan LÃhr wrote:
> > Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman:
> >> On 22 Oct 2004, Jan LÃhr wrote:

> Yes, and that is one of the core points in my suggestion that you look
> at SELinux or a similar mandatory access control based security module.

SELinux is overkill in some ways. A system adminstrator, not being able to 
handle ACLs won't be able to handle SELinux.

> [...]
>
> > Of course not. But on the other hand, there are parts of the system, a
> > deamon user should not be able to stick his nose in. Imho a more
> > restrictive way is necessary.
>
> MAC allows you to actually enforce these rules, rather than simply
> making it a bit harder or the mechanism a bit more obscure.
>
> As people have been saying for years, security through obscurity is no
> real security at all -- and preventing access to on-disk binary code
> does not prevent access to the risky areas.

Well, standard debian binary code is available for nearly everyone. Sec-by-obs 
by setting fs-rights was not in my intention.

> [...]
>
> >> I think that trying to enforce this sort of security at the filesystem
> >> level is doomed to failure, as it is the wrong level to work at.
> >
> > Ok, but why should lp (as user) be able to access mount (suid)? I see no
> > reason to allow them to do so, but I see many reasons for not allowing
> > them to do so.
>
> They shouldn't be able to access mount, or related functionality.
>
> Trying to enforce that through filesystem permissions is a task that has
> a large number of failure points, especially in the face of multiple
> vulnerabilities.

Of course. But even chrooting everything was exploited in past. If you are a 
victim of multiple vulns - god bless you.

> One of the most common failures for this sort of security is a copy of
> the binary accessed through another path name, etc, that allows the
> undesired code to be executed despite protection in of the main copy.

If a file can be accessed through some link, loading, etc. tricks sec. on 
fs-level is not implemented correctly. Without taking control over 
kernel-functions (like root-kits do, but you have to be root to do so) no one 
should be able to bypass the file-system layer. The best example for this is 
mounting partition's noexec. Everyone, who has sticked is nose into that 
topic is able to bypass this flag, but programs like dpkg are not able to do 
there work, if /tmp is mounted noexec - strange world. If the non-execution 
idea was implemented correctly neither this bypass nor  any other would be 
possible. (I'd like to append, that Imho the current linux kernel / userland 
architecture is unable to allow a clean implementation of this).

>
> Also, trying to define the security rules at the filesystem level
> provides no real protection against many locally exploitable holes.
> Many of these can be accessed by talking over network sockets or other
> channels than the filesystem.

If you gain root, everything is possible on a root centric-system. Using 
non-root-centric systems is tending to confuse naive admins.

> >> If you want to achieve this sort of high level security by default,
> >> consider finding and working with the people who are trying to provide
> >> the tools and environment required to run SELinux, or some other MAC
> >> implementation, in Debian.
> >
> > NSA is evil by default ;-)
>
> The code is all out there; feel free to audit it. ;)

Well, I've some other work to do in the next months. ;-)
> Alternatively, trust some other group who write LSM code to implement a
> MAC system, or even one of the alternative security models, and work on
> getting that into Debian as an option or, eventually, by default.
>
> I named SELinux because I know there to be a real effort to get this
> working out of the box, not because I have any special love for it.

Well, yeah. But peopple who developed trojan horses like magic like magic 
latern are not trustworthy in my opinion. ;-)

> > Of course, providing security on that level is not the best way to
> > ensure the system's integrity and safety. But why do you think, that
> > security on filesystem level is doomed to failure if it's part of a
> > security concept? The introduction of shadow passwords use the concept
> > of file system level security. Imho allowing $daemon to access
> > $some-unnecessary-suid-binary is doomed to failure.
>
> You may note that the shadow password system has also moved on, to
> include other methods for encrypting the password since, at the end of
> the day, these filesystem permissions can be bypassed. :)

Of course, at the end of these days, even bypassing of chroot and vmware is 
documented.

> You are right when you say that using filesystem permissions can provide
> some measure of additional security, and when you say that the
> introduction of an ACL capability into many common filesystems in Linux
> opens the door to enabling thi

Re: Security issue? Daemon users has to much rights...

2004-10-22 Thread Jan Lühr
Greetings,

Am Freitag, 22. Oktober 2004 14:02 schrieb Daniel Pittman:
> On 22 Oct 2004, Jan LÃhr wrote:
> > because of the recent xpdf issues I tested the access restrictions of
> > some users like lp, mail, etc. with default settings in sarge. I noticed
> > that, by default, no acl were used to prevent access to vital system
> > commands, the user shouldn't have. For instance: lp could mount a vfat
> > partion marked as user mountable in fstab, execute df or mount to gain
> > information about the systems topology.
>
> I don't think that you understand what an "ACL", or Access Control List,
> is -- or, possibly, you have learned an uncommon use of that terminology
> elsewhere.
>
> Access Control Lists are almost always used in the context of extended
> filesystem permissions, as a way of granting or revoking more than the
> simple user/group/other spilt traditional to Unix.

sure.

> They are not the usual technology used to provide access partitioning to
> the system in the style you suggest above, although they can in some
> cases make it easier to implement that sort of security policy.

Of course.

> This is, in large part, because preventing access to the binaries
> commands on disk does little or nothing to prevent a determined attacker
> from gaining the equivalent functionality through directly calling the
> kernel.

That's true as well. But the binaries are just an example for unnecessary 
rights.

> Even preventing them from having access to libc doesn't really help
> much. :)

Of course not. But on the other hand, there are parts of the system, a deamon 
user should not be able to stick his nose in. Imho a more restrictive way is 
necessary.
For instance access to the mount command is not that critical, but hijacked 
daemons (take a hijacked cups for instance) allow to use local root exploits, 
a remote attacker would never have been able to. Forgotten suid-binaries are 
a great risk.

> > By introducing acl's in late 2.4 and 2.6 (both are the main kernel
> > branches for sarge and are used during the installaion), it might be
> > worth the effort to introduce default ACLs during the installation
> > process (optional of course) in order to protect systems not managed by
> > skilled admins. (rentable server, etc.)
> > What do you think?
>
> I think that trying to enforce this sort of security at the filesystem
> level is doomed to failure, as it is the wrong level to work at.

Ok, but why should lp (as user) be able to access mount (suid)? I see no 
reason to allow them to do so, but I see many reasons for not allowing them 
to do so.

> If you want to achieve this sort of high level security by default,
> consider finding and working with the people who are trying to provide
> the tools and environment required to run SELinux, or some other MAC
> implementation, in Debian.

NSA is evil by default ;-)

Of course, providing security on that level is not the best way to ensure the 
system's integrity and safety.
But why do you think, that security on filesystem level is doomed to failure 
if it's part of a security concept?
The introduction of shadow passwords use the concept of file system level 
security.
Imho allowing $daemon to access $some-unnecessary-suid-binary is doomed to 
failure.

> > Who's in charge with this decision?
>
> I don't think you could succeed in having this imposed by fiat on the
> Debian project, especially at this late stage, since it would be a huge
> level of work.

Well, yes. Sid might be a target as well.

Keep smiling
yanosz



Security issue? Daemon users has to much rights...

2004-10-22 Thread Jan Lühr
Greetings,

because of the recent xpdf issues I tested the access restrictions of some 
users like lp, mail, etc. with default settings in sarge. I noticed that, by 
default, no acl were used to prevent access to vital system commands, the 
user shouldn't have. For instance: lp could mount a vfat partion marked as 
user mountable in fstab, execute df or mount to gain information about the 
systems topology.
By introducing acl's in late 2.4 and 2.6 (both are the main kernel branches 
for sarge and are used during the installaion), it might be worth the effort 
to introduce default ACLs during the installation process (optional of 
course) in order to protect systems not managed by skilled admins. (rentable 
server, etc.)
What do you think?
Who's in charge with this decision?

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: CAN-2003-0020?

2004-04-18 Thread Jan Lühr
Greetings,

Am Sonntag, 18. April 2004 18:56 schrieb Matt Zimmerman:
> On Sat, Apr 17, 2004 at 10:16:11PM +0200, Jan L??hr wrote:
> > what about
> > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? Is
> > debian finally going to fix it?
>
> Current consensus between the security team and the Apache maintainers is
> that it is not necessary to fix this in woody.

Ehm... why ? ;) 
What about sarge or sid?

Keep smiling
yanosz



Re: CAN-2003-0020?

2004-04-18 Thread Jan Lühr
Greetings,

Am Sonntag, 18. April 2004 18:56 schrieb Matt Zimmerman:
> On Sat, Apr 17, 2004 at 10:16:11PM +0200, Jan L??hr wrote:
> > what about
> > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? Is
> > debian finally going to fix it?
>
> Current consensus between the security team and the Apache maintainers is
> that it is not necessary to fix this in woody.

Ehm... why ? ;) 
What about sarge or sid?

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



CAN-2003-0020?

2004-04-17 Thread Jan Lühr
Greetings,

what about http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? 
Is debian finally going to fix it?

keep smiling
yanosz



CAN-2003-0020?

2004-04-17 Thread Jan Lühr
Greetings,

what about http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020 ? 
Is debian finally going to fix it?

keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-15 Thread Jan Lühr
Greetings,

Am Mittwoch, 14. April 2004 23:08 schrieb Phillip Hofmeister:
> If you checked the reference CVE numbers you should be able to tell when
> the exposure first occurred (or close to it).
>
Thanks :) - I have already been there. Are there any, no longer classified 
information about the fixing process?

Keep smilling
yanosz



Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-15 Thread Jan Lühr
Greetings,

Am Mittwoch, 14. April 2004 23:08 schrieb Phillip Hofmeister:
> If you checked the reference CVE numbers you should be able to tell when
> the exposure first occurred (or close to it).
>
Thanks :) - I have already been there. Are there any, no longer classified 
information about the fixing process?

Keep smilling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-14 Thread Jan Lühr
Greetings,..

Am Mittwoch, 14. April 2004 20:57 schrieben Sie:
> Jan Lühr <[EMAIL PROTECTED]> writes:
> > Greetings,

> Okay... This is the result of a cursory check, do your homework, yada,
> yada...
>

Thanks for doing so ;) Anyway, this wasn't the intetention of my post.
My point is, that five local root exploits at once are a little bit scary, as 
far as there are no patch- days for debian ;). So I'd like to know, which of 
them might have been fixed earlier.
It's just my interest to track the linux-sec-efforts from my point of view.

Keep smiling
yanosz



Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-14 Thread Jan Lühr
Greetings,..

Am Mittwoch, 14. April 2004 20:57 schrieben Sie:
> Jan Lühr <[EMAIL PROTECTED]> writes:
> > Greetings,

> Okay... This is the result of a cursory check, do your homework, yada,
> yada...
>

Thanks for doing so ;) Anyway, this wasn't the intetention of my post.
My point is, that five local root exploits at once are a little bit scary, as 
far as there are no patch- days for debian ;). So I'd like to know, which of 
them might have been fixed earlier.
It's just my interest to track the linux-sec-efforts from my point of view.

Keep smiling
yanosz



Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-14 Thread Jan Lühr
Greetings,

Am Mittwoch, 14. April 2004 16:52 schrieb Martin Schulze:
> --
> Debian Security Advisory DSA 479-1 [EMAIL PROTECTED]
> http://www.debian.org/security/ Martin Schulze
> April 14th, 2004http://www.debian.org/security/faq
> --
>
> Package: kernel-source-2.4.18 kernel-image-2.4.18-1-alpha
> kernel-image-2.4.18-1-i386 kernel-image-2.4.18-i386bf
> kernel-patch-2.4.18-powerpc Vulnerability  : several vulnerabilities
> Problem-Type   : local
> Debian-specific: no
> CVE ID : CAN-2004-0003 CAN-2004-0010 CAN-2004-0109 CAN-2004-0177
> CAN-2004-0178

puh - synchronised with the realese 2.4.26 and no warnings of bugtraq or fd... 
Good work.
I imagine that everything is fixed in 2.4.26.
Does someone know if 2.4.26 is a bugfix pre-release?
I'm getting a little bit confused right know, if there are serious issue with 
the kernel, why wasn't there any earlier release of 2.4.26?

Refering to the large number of fixed vuln, might an earlier release of single 
patches has been an option? Or did you watch fd to find the right time?

Keep smiling
yanosz 





Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

2004-04-14 Thread Jan Lühr
Greetings,

Am Mittwoch, 14. April 2004 16:52 schrieb Martin Schulze:
> --
> Debian Security Advisory DSA 479-1 [EMAIL PROTECTED]
> http://www.debian.org/security/ Martin Schulze
> April 14th, 2004http://www.debian.org/security/faq
> --
>
> Package: kernel-source-2.4.18 kernel-image-2.4.18-1-alpha
> kernel-image-2.4.18-1-i386 kernel-image-2.4.18-i386bf
> kernel-patch-2.4.18-powerpc Vulnerability  : several vulnerabilities
> Problem-Type   : local
> Debian-specific: no
> CVE ID : CAN-2004-0003 CAN-2004-0010 CAN-2004-0109 CAN-2004-0177
> CAN-2004-0178

puh - synchronised with the realese 2.4.26 and no warnings of bugtraq or fd... 
Good work.
I imagine that everything is fixed in 2.4.26.
Does someone know if 2.4.26 is a bugfix pre-release?
I'm getting a little bit confused right know, if there are serious issue with 
the kernel, why wasn't there any earlier release of 2.4.26?

Refering to the large number of fixed vuln, might an earlier release of single 
patches has been an option? Or did you watch fd to find the right time?

Keep smiling
yanosz 




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:20 schrieb Nathan Eric Norman:
> On Mon, Mar 22, 2004 at 10:01:14PM +0100, Jan Lühr wrote:
> > Greetings,
> >
> > Am Montag, 22. März 2004 21:16 schrieb Bryan Allen:
> > > On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote:
> > > > Cron is another example - the be honest, the debian security team
> > > > seems to be
> > > > crippled by the debian release policy.
> > > > Because of this policy debian stable is insecure by definition.
> > >
> > > http://security.debian.org/
> > >
> > > You are asked on install if you would like to use it. The default is
> > > "yes".
> >
> > 
> > I did so, but I didn't get all necessary patches - did I do something
> > wrong? 
>
> You opened a bug on cron and supplied links to the patches you're
> talking about, right?  For some reason I don't see any open bugs on
> cron with your name on them.

Sorry, there was a misunderstanding between Florian and me (in a previous 
e-mail correspondence). I'd like to cancel my statements about cron - my 
apologies.

Keep smiling
yanoszu

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9eqtAHMQ8GQaYRAQLh6hAAnDcBcOT/bn31OTvtgzibj26bOQgP22Q5
j93+L0+odxV1FKjLFiE3vsAAaBzut8Px5/9r84yHUNm/LfPhPJWlASrtsXbG9S9Z
4FO8FkQWR6/lj1ejpqRK7aGUAEsb7jwDzJbcXKwzNrtK56BekSxClRatXc8B6nL9
x3MDvrV0coYDXTF7zTezAP4xaWbuzcBwdUOQu41HsxvYRbUy1jNeO9lCeNXQWn2M
tjTlKibzRHNQJd6Cao/JWhN4ZObdYFW1GqJCNl3ZnmN0PZptr0TlCABlstDH9Z3s
16vWs+lk0nyctM0yyYtkSiKaw8XMMkiZAgixkvP0s9MEUsEKz9fXM+cW9juv38Pf
1mRDLeQwF+KCDeF2cBzT5Q24YRypzLbEoqoZBMFhY0HnDdi1V7/B1vm3tprchz+Q
eWcKdlJ8uM1LPMNDMOlM5W1tyI34ZAnVuo9etgOeUCFgSFa6I25Cj+ZiY0m5kyER
6mIELZixHzQHv33QC4e3zGU5vJPjNAwMic6wSB/aThy1hUxAQHp1Mu2qeBokigZN
jC5xvwohEb0kLkK/izfvUz6mMH3kkSVjU4dbHP4Eni4OjAH23UnVVnqafQnpz3ni
4fJTfGNWPPQeAtVaov2Jg/ashwO0OeEh83kFmWoxedgLVOFkRRGcTiRHdfhFwzMh
7yivSHXY+G8=
=v8DJ
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:52 schrieb Ramon Kagan:
> Every so often another set of tirades goes across this list.  So I wish
> only to give my 2 cents.
>
> 1.  If you don't like the way debian conducts it's FREE business, my
> opinion is go find another volunteer group to haggle.

ehem. What about critics? Am I not allowed to critices their work? As I have 
pointed out, their is no alternative for it. "But the point is: what's the 
alternative? If $big_fat_distributer is crippled
by its own release policy or profit making intention - they will _NEVER_ be
secure." I said. 

So the debian security team is doing a good job at the whole.

> 2.  If you are going to complain about something you don't like, then
> either be constructive about it, i.e. say this could be fixed by ... or
> can I help in some way..., or just stop wasting my time and others on this
> list.

I made my suggestions how to fix it.

> 3.  Debian is a testament to the ability of a VOLUNTEER system working
> across multiple countries and continents to provide a good service.  Is it
> perfect?  Probably not, but I haven't found a paid service that is either.
> Remember you are not a paying customer, so what right do you have in
> complaining in not constructive matter?

100% ACK.

> 4.  I would like to thank all the volunteers in the Debian organization
> for all the hard work they do to make my life easier and more productive.
> You all deserve KUDOS.

m2.

> As for the complainers, either shape up or ship out, we never asked you to
> use the product.  Go get yourself a copy of RedHat and see how "wonderful"
> their product is.

Well, I pointed out that there is not real alternative. Imho the current 
release policy doesn't support the creation of a secure distribution.

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9c4dAHMQ8GQaYRAQLqPA//cFN7DgJ7NPljQTPlT6p1qYFo3xr2bosK
N4lNbVkaJQt33IcYwpSBn0HlIBfr0CEpHQeuKy6mFobGvHNggzIHH0ulfhAeIGX+
cU9wSS4QGhhrvxPnU3MF5DnKzgBPVo13jxDRBBjmjyp5xyoE2/AQMJ+nEyqxtWF7
uWYczepYv4cGzsDRcHgskAq6n65Cng5wOQyMdLOpCJES1hFum+i2dj0VPYFNUsuI
UOp+r8QX4k6gSJUxlYwJ6zDURm7YQPLo1D24KBazUc37WdpHxs3uOOVFmGL1Pe5k
UXxfffE59ed63rNJDBBRFp+IsSiPwWBjhs5fZxRJ3Il0fB6fQBXqv5qTXlQSbazL
u1tm4rcxQLApO+gGhxjwU5BKQAEtLj9TaPWKzzVppdpHn9K+WSFF3pSlkAZCSEvF
Qm89wRELroof6tPn6nBI11MMG45fOeeBMMys3mfjQhoIx1hV+1p2t4SgteRAfCDp
sgtm4WqgXWrGvcO0PG6PLz9/j+UaGU6qetVCwg/rMaEf3aByZXplqw2aJMxzJfrW
KNcJ0knE7X/Eymo9ewQnoZzcHnF3uHsSA0QXNc5wwh5EORsuV29pFIwu0+RLwCY6
1t5vzTXXA3xTp+NYi8qUHft+9SF0IkaBd4rNmCbQboNAof5LvsuQvdp/mDmUwiOn
9AQaXWZbAQU=
=QBQS
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:16 schrieb Bryan Allen:
> On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote:
> > Cron is another example - the be honest, the debian security team
> > seems to be
> > crippled by the debian release policy.
> > Because of this policy debian stable is insecure by definition.
>
> http://security.debian.org/
>
> You are asked on install if you would like to use it. The default is
> "yes".

I did so, but I didn't get all necessary patches - did I do something wrong?


Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9UINAHMQ8GQaYRAQJHVhAAkYhW7RGPvMLltPbsHjB1v3YvD/xraXNQ
PuTsZxoBFRY2p1uMJ9WMef0lLwLwPLjJ+8lT5yC613sbZH5Oskc9J7+50F3NiMjC
zxWMETBstzGxO03FDlCif/7YJ6w4lCMPJbloTpwKGRNyyVp+0udBoUNmwXg62nyy
Ek7TdGFsBqGHQaTxWwVNSw8oJB9MtLc2gVZ/OmCxYhiRe9AfWWl9IVZG5UDo18ys
FixoahoLlayPpAdbNYJM49KWBxJjntWJ+UnIwCrfnhFpEJlDSdym8JctrMbbWY/1
R4+hwfU5cQY/g8RoSZtqNf4zq+cKI6cyB05s/we5jJ6pIGGRufOTlLT/U6Gy7nok
EiPhRCV8+nwvrNOSpjGMGjTLj06T9TgmRcwAhFphbu8mvNJ/7YW2ZIU6OHCEWTSN
0m1+mXVHqGjPcIeDOVWbQ5iWcOgoexGvr/Qn/sNiMXESIXIQ4+AY+YPFPAImA6sm
mMWgYaK9uKVJL7pMhAPWBxnBoat7qjzIYLdJ/PTI5Cbj7iiwcXbHejcbO2Tu0Kb/
MKS/Zd5i0PKZTSKkgxaBVJUKhb907nPJf7+aiBYXIkOTsZuceoe6WRTW/rhAUiUB
/DJVeYle6KE3SkojAm9xFNDMv3LH6UY2OKD05ypEhOVLBMHgIx+Fm00yfgMwRoT8
VFq884bD1hU=
=Vbmb
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,...

Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman:
> On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote:
> > Cron is another example
>
> Cron is another example of what?  By all means, please elaborate.

Of a package of the discussed categorie.

> > - the be honest, the debian security team seems to be crippled by the
> > debian release policy.  Because of this policy debian stable is insecure
> > by definition.
>
> If you have concrete information about unfixed bugs, bring it forth.
> Otherwise this is just more FUD.

Moz bug 228176 [1] is an example.

Keep smiling
yanosz

[1] http://bugzilla.mozilla.org/show_bug.cgi?id=228176
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9QU9AHMQ8GQaYRAQK4LRAAiGzERvEsWzhVZQyipGRmS1NguwKEpi/M
78sGIya2VDcgrsyGquRloQn9xdEI5iIVZcVqj8QLXUw05B5K76Qdym87/uzS6px1
BjyccCtERxgISkjLKVB+CK8pfzl9K+lTOkMHPHFcfWo5dUtqp3nVBjXxGgXABKix
hGhsODxXMsmPk3IsW7xyAquUeRMs/NrDRRNNGwfTryMRFS6CO2g2OjBBnq17HKap
9ZYCcEhmZO226I8g4uL8tPSo+Dxt+l0Eirh2exhTsMuuLZj9N8Tqtx5owEW41KoN
SEr1rjDC5a7Jv9jJfChRnc/dpNbuwn5A+lavk9cJI9WD0SE7W1Zc3+W71gh/M9RQ
RBezUlNPi58+dE8A7weElyO3rnqZexNYvcm+3wF5Gj7+I1zQUz4f4A4IFYWH7q0q
Xt0gxAmVVcZAwrZrBXcAAijw0P3MfavxNpDUq9cs8t6SI9Canv63uEgqyflrgxUL
nEzfMFbi5ndeRyi+gRz5MSzbJId+5sjL9rNkkgdzyBlgyzb7sBsq4UdKZyD8IWnK
pj9Fc94WiSsWk0WbUoCECdUlbhJIW77NY7JiH6GcjFr3mo4vTh90nnHcAVhgjkIh
8oIfObG9LalWkjbc/zk26xx3xLK58j9F+NwAXSrzkCCV5JiO5TbUl2KyQHN59MpJ
DL0/E5wKDk4=
=NRUA
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 19:30 schrieb Sven Hoexter:
> On Mon, Mar 22, 2004 at 06:57:39PM +0100, Giacomo Mulas wrote:
> > There is a \begin{sarcasm} nice \end{sarcasm} article in
> > linuxworld Australia (see
> > http://www.linuxworld.com.au/index.php/id;1607539824;fp;2;fpid;1) which,
> > among other things, claims that "Debian (Debian GNU/Linux) has left
> > vulnerabilities there and didn't release any patches for them". 

Imho this article is about 90% percent correct - 95% percent if you ignore the 
marketing waste.
5% not, because the article put specific facts into general. The debian 
distribution in whole is an easy target for hackers. The point is: If you 
want to built a secure operating system you have to know exactly what you are 
doing. What are the current vuln of the program I'm currently installing? 
What do I have to do to work around them? Are there any known bugs? What does 
the changelog say about these version? Have all fixes been backported to 
debian?
The mozilla problem is one of the best examples what debian is into. If you 
trust in the ability of the debian project to release a secure distribution 
you are a fool!

But the point is: what's the alternative? If $big_fat_distributer is crippled 
by its own release policy or profit making intention - they will _NEVER_ be 
secure.
Debian might be more secure, if they recognise, that security gathered 
importance.
btw. There was / is / won't be any absolutly secure operating system, covering 
the needs of an ordinary modern server.

>
> Well a week ago or so we had a longer discussion here about open bugs left
> in the ancient mozilla version in woody.

discussion without conclusion I must admit - sadly.
It might be to necessary to file as many rc-bugs to the current packages 
(mozilla, cron e.g.) as possibly. Thus debian-sarge might never be releases 
(who want to release sarge with 1000-2000 sec. bugs - it might be worth the 
effort).
It it's done that way, the leadership of the project will have to decide, 
whether they want to ignore sec. aspects and release sarge by as many 
laughter as neccessary or change the release policy or never release sarge.

Sadly - I don't have access to secret information (cve, etc.) which would be 
needed to do so.

> That's the only example I know but that doesn't mean much.

Cron is another example - the be honest, the debian security team seems to be 
crippled by the debian release policy.
Because of this policy debian stable is insecure by definition.

Regards
J.Luehr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9FLNAHMQ8GQaYRAQKGGg//ROiiYIX/3ttelj+58StXXwwS0Kkpfps5
GK3eVIiG/BIjR/VNnH9gVYVU9pEL/ot/S/8t9Bd3V4Bv/rPKacfeNUuulRwRo8Su
Nh8gochz0KQl/FQbr853VGgbBcCg/CCEJPeqtYwpxHqEXgkfYA0xQcYkRdRKZ+nd
IKYacu2aqqF1cfFt4A9bhi67pR2byzJn8U8SN0iBL/lkGSlq5GjMuUwxDzqfqar8
ZeuCTFeTGiL9ftNJQV1YpnM3U/Ya3Wx64E3tYG2+HfKl1AvSmz2rmz8QpHQi2tPm
5oxTQ80yYDqJW4FSrPXt0cSVsYLZjGo0IZif64kBEb39K/tLlLkG+HrLdS+8uPuM
AwR83aBg3MNHbNtYo/nPF3OqWGbOzyUvtmESZlBsEesgeZNEFjt91qkk/GFNfOBA
uJhw63VvzPXZSvuKkRtsWS+nx2VEODYNoUmFER0ZOZQXc+mslTEBoiODbB3JgA8A
tlYt5egSXh0ULCGPqqgVvF60F4T+yFxp2yjyHmVdWm6gBTu8d2rTr5sUukkLqRwC
7MRc1uMdL/XM4I5+nUwhA2DhCywEPjmDt1UpHdk+hvzDO9ybp8IzvwMVw+yMV51G
HPOemUBwlgXxPE0fNJ5KgwUmmxUb6VUVddfLBCK0xCijksS9+T/L0o8SUt0Yi8yW
zfwAI+1dgcU=
=VFzq
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:20 schrieb Nathan Eric Norman:
> On Mon, Mar 22, 2004 at 10:01:14PM +0100, Jan Lühr wrote:
> > Greetings,
> >
> > Am Montag, 22. März 2004 21:16 schrieb Bryan Allen:
> > > On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote:
> > > > Cron is another example - the be honest, the debian security team
> > > > seems to be
> > > > crippled by the debian release policy.
> > > > Because of this policy debian stable is insecure by definition.
> > >
> > > http://security.debian.org/
> > >
> > > You are asked on install if you would like to use it. The default is
> > > "yes".
> >
> > 
> > I did so, but I didn't get all necessary patches - did I do something
> > wrong? 
>
> You opened a bug on cron and supplied links to the patches you're
> talking about, right?  For some reason I don't see any open bugs on
> cron with your name on them.

Sorry, there was a misunderstanding between Florian and me (in a previous 
e-mail correspondence). I'd like to cancel my statements about cron - my 
apologies.

Keep smiling
yanoszu

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9eqtAHMQ8GQaYRAQLh6hAAnDcBcOT/bn31OTvtgzibj26bOQgP22Q5
j93+L0+odxV1FKjLFiE3vsAAaBzut8Px5/9r84yHUNm/LfPhPJWlASrtsXbG9S9Z
4FO8FkQWR6/lj1ejpqRK7aGUAEsb7jwDzJbcXKwzNrtK56BekSxClRatXc8B6nL9
x3MDvrV0coYDXTF7zTezAP4xaWbuzcBwdUOQu41HsxvYRbUy1jNeO9lCeNXQWn2M
tjTlKibzRHNQJd6Cao/JWhN4ZObdYFW1GqJCNl3ZnmN0PZptr0TlCABlstDH9Z3s
16vWs+lk0nyctM0yyYtkSiKaw8XMMkiZAgixkvP0s9MEUsEKz9fXM+cW9juv38Pf
1mRDLeQwF+KCDeF2cBzT5Q24YRypzLbEoqoZBMFhY0HnDdi1V7/B1vm3tprchz+Q
eWcKdlJ8uM1LPMNDMOlM5W1tyI34ZAnVuo9etgOeUCFgSFa6I25Cj+ZiY0m5kyER
6mIELZixHzQHv33QC4e3zGU5vJPjNAwMic6wSB/aThy1hUxAQHp1Mu2qeBokigZN
jC5xvwohEb0kLkK/izfvUz6mMH3kkSVjU4dbHP4Eni4OjAH23UnVVnqafQnpz3ni
4fJTfGNWPPQeAtVaov2Jg/ashwO0OeEh83kFmWoxedgLVOFkRRGcTiRHdfhFwzMh
7yivSHXY+G8=
=v8DJ
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:52 schrieb Ramon Kagan:
> Every so often another set of tirades goes across this list.  So I wish
> only to give my 2 cents.
>
> 1.  If you don't like the way debian conducts it's FREE business, my
> opinion is go find another volunteer group to haggle.

ehem. What about critics? Am I not allowed to critices their work? As I have 
pointed out, their is no alternative for it. "But the point is: what's the 
alternative? If $big_fat_distributer is crippled
by its own release policy or profit making intention - they will _NEVER_ be
secure." I said. 

So the debian security team is doing a good job at the whole.

> 2.  If you are going to complain about something you don't like, then
> either be constructive about it, i.e. say this could be fixed by ... or
> can I help in some way..., or just stop wasting my time and others on this
> list.

I made my suggestions how to fix it.

> 3.  Debian is a testament to the ability of a VOLUNTEER system working
> across multiple countries and continents to provide a good service.  Is it
> perfect?  Probably not, but I haven't found a paid service that is either.
> Remember you are not a paying customer, so what right do you have in
> complaining in not constructive matter?

100% ACK.

> 4.  I would like to thank all the volunteers in the Debian organization
> for all the hard work they do to make my life easier and more productive.
> You all deserve KUDOS.

m2.

> As for the complainers, either shape up or ship out, we never asked you to
> use the product.  Go get yourself a copy of RedHat and see how "wonderful"
> their product is.

Well, I pointed out that there is not real alternative. Imho the current 
release policy doesn't support the creation of a secure distribution.

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9c4dAHMQ8GQaYRAQLqPA//cFN7DgJ7NPljQTPlT6p1qYFo3xr2bosK
N4lNbVkaJQt33IcYwpSBn0HlIBfr0CEpHQeuKy6mFobGvHNggzIHH0ulfhAeIGX+
cU9wSS4QGhhrvxPnU3MF5DnKzgBPVo13jxDRBBjmjyp5xyoE2/AQMJ+nEyqxtWF7
uWYczepYv4cGzsDRcHgskAq6n65Cng5wOQyMdLOpCJES1hFum+i2dj0VPYFNUsuI
UOp+r8QX4k6gSJUxlYwJ6zDURm7YQPLo1D24KBazUc37WdpHxs3uOOVFmGL1Pe5k
UXxfffE59ed63rNJDBBRFp+IsSiPwWBjhs5fZxRJ3Il0fB6fQBXqv5qTXlQSbazL
u1tm4rcxQLApO+gGhxjwU5BKQAEtLj9TaPWKzzVppdpHn9K+WSFF3pSlkAZCSEvF
Qm89wRELroof6tPn6nBI11MMG45fOeeBMMys3mfjQhoIx1hV+1p2t4SgteRAfCDp
sgtm4WqgXWrGvcO0PG6PLz9/j+UaGU6qetVCwg/rMaEf3aByZXplqw2aJMxzJfrW
KNcJ0knE7X/Eymo9ewQnoZzcHnF3uHsSA0QXNc5wwh5EORsuV29pFIwu0+RLwCY6
1t5vzTXXA3xTp+NYi8qUHft+9SF0IkaBd4rNmCbQboNAof5LvsuQvdp/mDmUwiOn
9AQaXWZbAQU=
=QBQS
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 21:16 schrieb Bryan Allen:
> On Mar 22, 2004, at 2:57 PM, Jan Lühr wrote:
> > Cron is another example - the be honest, the debian security team
> > seems to be
> > crippled by the debian release policy.
> > Because of this policy debian stable is insecure by definition.
>
> http://security.debian.org/
>
> You are asked on install if you would like to use it. The default is
> "yes".

I did so, but I didn't get all necessary patches - did I do something wrong?


Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9UINAHMQ8GQaYRAQJHVhAAkYhW7RGPvMLltPbsHjB1v3YvD/xraXNQ
PuTsZxoBFRY2p1uMJ9WMef0lLwLwPLjJ+8lT5yC613sbZH5Oskc9J7+50F3NiMjC
zxWMETBstzGxO03FDlCif/7YJ6w4lCMPJbloTpwKGRNyyVp+0udBoUNmwXg62nyy
Ek7TdGFsBqGHQaTxWwVNSw8oJB9MtLc2gVZ/OmCxYhiRe9AfWWl9IVZG5UDo18ys
FixoahoLlayPpAdbNYJM49KWBxJjntWJ+UnIwCrfnhFpEJlDSdym8JctrMbbWY/1
R4+hwfU5cQY/g8RoSZtqNf4zq+cKI6cyB05s/we5jJ6pIGGRufOTlLT/U6Gy7nok
EiPhRCV8+nwvrNOSpjGMGjTLj06T9TgmRcwAhFphbu8mvNJ/7YW2ZIU6OHCEWTSN
0m1+mXVHqGjPcIeDOVWbQ5iWcOgoexGvr/Qn/sNiMXESIXIQ4+AY+YPFPAImA6sm
mMWgYaK9uKVJL7pMhAPWBxnBoat7qjzIYLdJ/PTI5Cbj7iiwcXbHejcbO2Tu0Kb/
MKS/Zd5i0PKZTSKkgxaBVJUKhb907nPJf7+aiBYXIkOTsZuceoe6WRTW/rhAUiUB
/DJVeYle6KE3SkojAm9xFNDMv3LH6UY2OKD05ypEhOVLBMHgIx+Fm00yfgMwRoT8
VFq884bD1hU=
=Vbmb
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,...

Am Montag, 22. März 2004 21:05 schrieb Matt Zimmerman:
> On Mon, Mar 22, 2004 at 08:57:26PM +0100, Jan L?hr wrote:
> > Cron is another example
>
> Cron is another example of what?  By all means, please elaborate.

Of a package of the discussed categorie.

> > - the be honest, the debian security team seems to be crippled by the
> > debian release policy.  Because of this policy debian stable is insecure
> > by definition.
>
> If you have concrete information about unfixed bugs, bring it forth.
> Otherwise this is just more FUD.

Moz bug 228176 [1] is an example.

Keep smiling
yanosz

[1] http://bugzilla.mozilla.org/show_bug.cgi?id=228176
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9QU9AHMQ8GQaYRAQK4LRAAiGzERvEsWzhVZQyipGRmS1NguwKEpi/M
78sGIya2VDcgrsyGquRloQn9xdEI5iIVZcVqj8QLXUw05B5K76Qdym87/uzS6px1
BjyccCtERxgISkjLKVB+CK8pfzl9K+lTOkMHPHFcfWo5dUtqp3nVBjXxGgXABKix
hGhsODxXMsmPk3IsW7xyAquUeRMs/NrDRRNNGwfTryMRFS6CO2g2OjBBnq17HKap
9ZYCcEhmZO226I8g4uL8tPSo+Dxt+l0Eirh2exhTsMuuLZj9N8Tqtx5owEW41KoN
SEr1rjDC5a7Jv9jJfChRnc/dpNbuwn5A+lavk9cJI9WD0SE7W1Zc3+W71gh/M9RQ
RBezUlNPi58+dE8A7weElyO3rnqZexNYvcm+3wF5Gj7+I1zQUz4f4A4IFYWH7q0q
Xt0gxAmVVcZAwrZrBXcAAijw0P3MfavxNpDUq9cs8t6SI9Canv63uEgqyflrgxUL
nEzfMFbi5ndeRyi+gRz5MSzbJId+5sjL9rNkkgdzyBlgyzb7sBsq4UdKZyD8IWnK
pj9Fc94WiSsWk0WbUoCECdUlbhJIW77NY7JiH6GcjFr3mo4vTh90nnHcAVhgjkIh
8oIfObG9LalWkjbc/zk26xx3xLK58j9F+NwAXSrzkCCV5JiO5TbUl2KyQHN59MpJ
DL0/E5wKDk4=
=NRUA
-END PGP SIGNATURE-



Re: Known vulnerabilities left open in Debian?

2004-03-22 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Montag, 22. März 2004 19:30 schrieb Sven Hoexter:
> On Mon, Mar 22, 2004 at 06:57:39PM +0100, Giacomo Mulas wrote:
> > There is a \begin{sarcasm} nice \end{sarcasm} article in
> > linuxworld Australia (see
> > http://www.linuxworld.com.au/index.php/id;1607539824;fp;2;fpid;1) which,
> > among other things, claims that "Debian (Debian GNU/Linux) has left
> > vulnerabilities there and didn't release any patches for them". 

Imho this article is about 90% percent correct - 95% percent if you ignore the 
marketing waste.
5% not, because the article put specific facts into general. The debian 
distribution in whole is an easy target for hackers. The point is: If you 
want to built a secure operating system you have to know exactly what you are 
doing. What are the current vuln of the program I'm currently installing? 
What do I have to do to work around them? Are there any known bugs? What does 
the changelog say about these version? Have all fixes been backported to 
debian?
The mozilla problem is one of the best examples what debian is into. If you 
trust in the ability of the debian project to release a secure distribution 
you are a fool!

But the point is: what's the alternative? If $big_fat_distributer is crippled 
by its own release policy or profit making intention - they will _NEVER_ be 
secure.
Debian might be more secure, if they recognise, that security gathered 
importance.
btw. There was / is / won't be any absolutly secure operating system, covering 
the needs of an ordinary modern server.

>
> Well a week ago or so we had a longer discussion here about open bugs left
> in the ancient mozilla version in woody.

discussion without conclusion I must admit - sadly.
It might be to necessary to file as many rc-bugs to the current packages 
(mozilla, cron e.g.) as possibly. Thus debian-sarge might never be releases 
(who want to release sarge with 1000-2000 sec. bugs - it might be worth the 
effort).
It it's done that way, the leadership of the project will have to decide, 
whether they want to ignore sec. aspects and release sarge by as many 
laughter as neccessary or change the release policy or never release sarge.

Sadly - I don't have access to secret information (cve, etc.) which would be 
needed to do so.

> That's the only example I know but that doesn't mean much.

Cron is another example - the be honest, the debian security team seems to be 
crippled by the debian release policy.
Because of this policy debian stable is insecure by definition.

Regards
J.Luehr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQF9FLNAHMQ8GQaYRAQKGGg//ROiiYIX/3ttelj+58StXXwwS0Kkpfps5
GK3eVIiG/BIjR/VNnH9gVYVU9pEL/ot/S/8t9Bd3V4Bv/rPKacfeNUuulRwRo8Su
Nh8gochz0KQl/FQbr853VGgbBcCg/CCEJPeqtYwpxHqEXgkfYA0xQcYkRdRKZ+nd
IKYacu2aqqF1cfFt4A9bhi67pR2byzJn8U8SN0iBL/lkGSlq5GjMuUwxDzqfqar8
ZeuCTFeTGiL9ftNJQV1YpnM3U/Ya3Wx64E3tYG2+HfKl1AvSmz2rmz8QpHQi2tPm
5oxTQ80yYDqJW4FSrPXt0cSVsYLZjGo0IZif64kBEb39K/tLlLkG+HrLdS+8uPuM
AwR83aBg3MNHbNtYo/nPF3OqWGbOzyUvtmESZlBsEesgeZNEFjt91qkk/GFNfOBA
uJhw63VvzPXZSvuKkRtsWS+nx2VEODYNoUmFER0ZOZQXc+mslTEBoiODbB3JgA8A
tlYt5egSXh0ULCGPqqgVvF60F4T+yFxp2yjyHmVdWm6gBTu8d2rTr5sUukkLqRwC
7MRc1uMdL/XM4I5+nUwhA2DhCywEPjmDt1UpHdk+hvzDO9ybp8IzvwMVw+yMV51G
HPOemUBwlgXxPE0fNJ5KgwUmmxUb6VUVddfLBCK0xCijksS9+T/L0o8SUt0Yi8yW
zfwAI+1dgcU=
=VFzq
-END PGP SIGNATURE-



Re: mozilla - the forgotten package?

2004-03-11 Thread Jan Lühr
Greetings,

Am Donnerstag, 11. März 2004 19:22 schrieb Phillip Hofmeister:
> On Thu, 11 Mar 2004 at 12:24:15PM -0500, Matt Zimmerman wrote:
> > This introduces a whole new set of problems, given Mozilla's upgrade
> > history (not preserving user configuration data, breaking compatibility
> > with dependent applications, etc.)
>
> We could offer a second Mozilla package, leaving the current on in place
> for compatibility sakes.

Good idea. Who is in charge with this decision?

Keep smiling
yanosz



Re: mozilla - the forgotten package?

2004-03-11 Thread Jan Lühr
Greetings,

Am Donnerstag, 11. März 2004 19:22 schrieb Phillip Hofmeister:
> On Thu, 11 Mar 2004 at 12:24:15PM -0500, Matt Zimmerman wrote:
> > This introduces a whole new set of problems, given Mozilla's upgrade
> > history (not preserving user configuration data, breaking compatibility
> > with dependent applications, etc.)
>
> We could offer a second Mozilla package, leaving the current on in place
> for compatibility sakes.

Good idea. Who is in charge with this decision?

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mozilla - the forgotten package?

2004-03-11 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 10. März 2004 22:39 schrieb Florian Weimer:
> Sven Hoexter wrote:
> > > Okay, if that's the case, I'm going to start a campaign for including
> > > Mozilla 1.4 (plus fixes) in stable.
> >
> > Well why just include 1.4 and not 1.6?
>
> AFAIK, 1.4 is the more stable branch, and fixes are still backported to
> it (at least by MandrakeSoft 8-).

Is that your campaign? 
http://cert.uni-stuttgart.de/ticker/article.php?mid=1183

Imho security fixes for mozilla are very important. Some exploits currently 
existing in mozilla justifies some rc bugs for mozilla.

Imho the consequences of being unable to provide sec. updates for a popular 
end-user client software is obvious: Kick the package out of stable, testing 
and unstable!
Being in stable implicies security, which is NOT provided. 

Just me 2cents.

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQFBtVdAHMQ8GQaYRAQLQDA//R5txp+sE7Iu7kJjaoaD/WDK43kN6GXr5
m0+LlQD/BuS8aOnoqFqo7Zbj+p+S/cVI4fZ9ZoR5w1WSgKk0Dn875af/fLTIUMFQ
DLpbI35KXwzSarSrya9P2tpBEXAQ2aLzhqnckureJ9s9uuxE0lcoYr6XnHBK90N2
0AcEzxeYMid04eqDGWK+TCEfDVm6g2XMnECEtJqxL3augt1tK7JXRNa9kOpkm3rZ
lN8ostQXZ5s8Fe84TXfz4iSOFYBy5HfqM3tp1h7od/02Zw8p6bSTg/KiRZHwnp89
w8IT3hghbSEFeLfA2NpPpo6HIEwmnH5O67nO2NgQ0SOCrElBf8VKr2bWin6Q999A
3vAB1M0vNpeRTiYwGYzztdH7yo6A+jkcuPZL1DRIPT4dChOotS6zmW3v0TY2MVU5
xKtDK2G6xIS8k0tZ7MZ13tD2flGq6Vc/SVlcmfmv9EgIDJQLcukV7EnJsUbAq5/J
jYTDOrWJ9K+leZ3obAswXLfNfJD6Hide/3CGrcf3WfARrlHaaRhWLBy1OrrrhL87
bYyJaONMEW+CQ3R39gBriuAjJ26o6ytssriErZkVnqUwWYovYV8/4I79jAd9vi4I
YOpB8fBpq2LI2fH5JtFa4N15tfECcouIDfH4fG5jHvZ3zFDb1hJAKUKNQ3zbSk1j
+yGIyCF6kq4=
=XlV6
-END PGP SIGNATURE-



Re: mozilla - the forgotten package?

2004-03-11 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 10. März 2004 22:39 schrieb Florian Weimer:
> Sven Hoexter wrote:
> > > Okay, if that's the case, I'm going to start a campaign for including
> > > Mozilla 1.4 (plus fixes) in stable.
> >
> > Well why just include 1.4 and not 1.6?
>
> AFAIK, 1.4 is the more stable branch, and fixes are still backported to
> it (at least by MandrakeSoft 8-).

Is that your campaign? 
http://cert.uni-stuttgart.de/ticker/article.php?mid=1183

Imho security fixes for mozilla are very important. Some exploits currently 
existing in mozilla justifies some rc bugs for mozilla.

Imho the consequences of being unable to provide sec. updates for a popular 
end-user client software is obvious: Kick the package out of stable, testing 
and unstable!
Being in stable implicies security, which is NOT provided. 

Just me 2cents.

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQFBtVdAHMQ8GQaYRAQLQDA//R5txp+sE7Iu7kJjaoaD/WDK43kN6GXr5
m0+LlQD/BuS8aOnoqFqo7Zbj+p+S/cVI4fZ9ZoR5w1WSgKk0Dn875af/fLTIUMFQ
DLpbI35KXwzSarSrya9P2tpBEXAQ2aLzhqnckureJ9s9uuxE0lcoYr6XnHBK90N2
0AcEzxeYMid04eqDGWK+TCEfDVm6g2XMnECEtJqxL3augt1tK7JXRNa9kOpkm3rZ
lN8ostQXZ5s8Fe84TXfz4iSOFYBy5HfqM3tp1h7od/02Zw8p6bSTg/KiRZHwnp89
w8IT3hghbSEFeLfA2NpPpo6HIEwmnH5O67nO2NgQ0SOCrElBf8VKr2bWin6Q999A
3vAB1M0vNpeRTiYwGYzztdH7yo6A+jkcuPZL1DRIPT4dChOotS6zmW3v0TY2MVU5
xKtDK2G6xIS8k0tZ7MZ13tD2flGq6Vc/SVlcmfmv9EgIDJQLcukV7EnJsUbAq5/J
jYTDOrWJ9K+leZ3obAswXLfNfJD6Hide/3CGrcf3WfARrlHaaRhWLBy1OrrrhL87
bYyJaONMEW+CQ3R39gBriuAjJ26o6ytssriErZkVnqUwWYovYV8/4I79jAd9vi4I
YOpB8fBpq2LI2fH5JtFa4N15tfECcouIDfH4fG5jHvZ3zFDb1hJAKUKNQ3zbSk1j
+yGIyCF6kq4=
=XlV6
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mozilla - the forgotten package?

2004-03-10 Thread Jan Lühr
Greetings,


Am Mittwoch, 10. März 2004 17:06 schrieben Sie:
> Jan Lühr wrote:
> > So is mozilla the forgotten package? Considering how popular mozilla is,
> > making it secure would be worth the effort - imho.
>
> How many of Mozilla's security bugs which are fix during routine
> upgrades are discussed publicly?  Can they be backported easily?

I'm not in touch with the mozilla code. Thus I cannot say how easy it is to 
backport 'em.

Keep smiling
yanosz



Re: mozilla - the forgotten package?

2004-03-10 Thread Jan Lühr
Greetings,


Am Mittwoch, 10. März 2004 17:06 schrieben Sie:
> Jan Lühr wrote:
> > So is mozilla the forgotten package? Considering how popular mozilla is,
> > making it secure would be worth the effort - imho.
>
> How many of Mozilla's security bugs which are fix during routine
> upgrades are discussed publicly?  Can they be backported easily?

I'm not in touch with the mozilla code. Thus I cannot say how easy it is to 
backport 'em.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
Greetings,

Am Dienstag, 9. März 2004 20:54 schrieb Noah Meyerhans:
> On Tue, Mar 09, 2004 at 08:53:23PM +0100, Jan L?hr wrote:
> > So this is all in all a capacity problem? Doesn't have the debian
> > security team enough ressource to port exisiting patches to debian
> > packages? Why not enlarging the team?
>
> You do not need to be a member of the security team to submit patches.
> Why don't you send some, and we'll release updated packages.

sorry, I'm not a good c++ coder. I'll think about it, when I'm able to do so.

Keep smiling
yanosz



Re: mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
Greetings,

Am Dienstag, 9. März 2004 17:20 schrieb Steve Kemp:
> On Tue, Mar 09, 2004 at 05:15:42PM +0100, Jan L??hr wrote:
> > over the last months, various security related bugs in mozilla appeared
> > and were fixed in new versions of mozilla - but what about the debian
> > package? Are there any efforts for making mozilla secure or to backport
> > the mozilla patches to debian?
> >
> > Due to depency with galeon new mozilla versions cannot be intergrated
> > easily, but right now, the debian mozilla contains some seriuos security
> > related bugs.
> >
> > So is mozilla the forgotten package? Considering how popular mozilla is,
> > making it secure would be worth the effort - imho.
>
>   I think it's a case of time and energy.  I started updating the
>  current woody packages to handle some of the reports, after mdz
>  pointed me to a list.
>
>   However it was very timeconsuming and very shortly after I started I
>  stopped having to support graphical stable boxes; so it became a non
>  issue for me.
>
>   There are patches around for some (most?) of the holes, it just takes
>  somebody with the patience to apply them and build fixed versions to
>  share - then I'm sure we'd see a new stable release.

So this is all in all a capacity problem? Doesn't have the debian security 
team enough ressource to port exisiting patches to debian packages?
Why not enlarging the team?

Keep smiling
yanosz



Re: mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
Greetings,

Am Dienstag, 9. März 2004 20:54 schrieb Noah Meyerhans:
> On Tue, Mar 09, 2004 at 08:53:23PM +0100, Jan L?hr wrote:
> > So this is all in all a capacity problem? Doesn't have the debian
> > security team enough ressource to port exisiting patches to debian
> > packages? Why not enlarging the team?
>
> You do not need to be a member of the security team to submit patches.
> Why don't you send some, and we'll release updated packages.

sorry, I'm not a good c++ coder. I'll think about it, when I'm able to do so.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
Greetings,

Am Dienstag, 9. März 2004 17:20 schrieb Steve Kemp:
> On Tue, Mar 09, 2004 at 05:15:42PM +0100, Jan L??hr wrote:
> > over the last months, various security related bugs in mozilla appeared
> > and were fixed in new versions of mozilla - but what about the debian
> > package? Are there any efforts for making mozilla secure or to backport
> > the mozilla patches to debian?
> >
> > Due to depency with galeon new mozilla versions cannot be intergrated
> > easily, but right now, the debian mozilla contains some seriuos security
> > related bugs.
> >
> > So is mozilla the forgotten package? Considering how popular mozilla is,
> > making it secure would be worth the effort - imho.
>
>   I think it's a case of time and energy.  I started updating the
>  current woody packages to handle some of the reports, after mdz
>  pointed me to a list.
>
>   However it was very timeconsuming and very shortly after I started I
>  stopped having to support graphical stable boxes; so it became a non
>  issue for me.
>
>   There are patches around for some (most?) of the holes, it just takes
>  somebody with the patience to apply them and build fixed versions to
>  share - then I'm sure we'd see a new stable release.

So this is all in all a capacity problem? Doesn't have the debian security 
team enough ressource to port exisiting patches to debian packages?
Why not enlarging the team?

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

over the last months, various security related bugs in mozilla appeared and 
were fixed in new versions of mozilla - but what about the debian package? 
Are there any efforts for making mozilla secure or to backport the mozilla 
patches to debian?
Due to depency with galeon new mozilla versions cannot be intergrated easily, 
but right now, the debian mozilla contains some seriuos security related 
bugs.
So is mozilla the forgotten package? Considering how popular mozilla is, 
making it secure would be worth the effort - imho.

Keep smiling
yanosz 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQE3ttNAHMQ8GQaYRAQLUkw//QQYCWCLtPhe6l2bFllP8cDeSbfPu6dCn
B1NpYneBP9lw5+feLfBMEzzKley2FXoSJTF6PMoEs8X5zSANPyMyRBvGRSyDq/Tf
X7zUojiIsr8xgdnHYZCXfCcdPIKU2qnJvYvnvWZPai4TT+4TU0qDhbe26q5klqmX
IC+YHuqUoeoaPHayKY2THurHS90Ex3qmB3LeZ7ngiAZWlEnscRNb+In/DSNXLdFg
9ViW67JOPYnGc5eHGrvVYZP/aIcJgsF6nEykHwf9Lef2dTs26aYZS2+5MV2NqB1z
XdgtA+Jtl+ISTnjvYTn8Zx7tsk4Nu1TrJHsdtCyCbqv4WSJW9eO5T8w1wScMVNRt
BBiQltSG4ZJNAlCb4uXZYxWCZ8mNH9BL8MmWJH4pCOoWOsjZV3Ve0e4IiLnbgyPH
ay0gQ/6vsweCm+vrSu4QIuLysx/yDD84cEOThRyccI8dgxdJc8FERaRu422pfsAS
/0HNh227kM3uqU/Ts/HlNG8jQWMrrr7nKjLA37pzXU9N13Vzu8gIwzyvQz3kMymm
25sxqkb4SifH61KAicjTOIXLQf4UBWlZHnaYTtCsc4BN7e3DmGwNy2Ozm5l7Fb76
Ji5+rVcLxf1UJedmlmruMc+XhvkdoCHuS057MGOb0hG6RpzZFB7/k9lvxFfLbM/B
SnDUvkzxJFk=
=e6ya
-END PGP SIGNATURE-



mozilla - the forgotten package?

2004-03-09 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

over the last months, various security related bugs in mozilla appeared and 
were fixed in new versions of mozilla - but what about the debian package? 
Are there any efforts for making mozilla secure or to backport the mozilla 
patches to debian?
Due to depency with galeon new mozilla versions cannot be intergrated easily, 
but right now, the debian mozilla contains some seriuos security related 
bugs.
So is mozilla the forgotten package? Considering how popular mozilla is, 
making it secure would be worth the effort - imho.

Keep smiling
yanosz 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQE3ttNAHMQ8GQaYRAQLUkw//QQYCWCLtPhe6l2bFllP8cDeSbfPu6dCn
B1NpYneBP9lw5+feLfBMEzzKley2FXoSJTF6PMoEs8X5zSANPyMyRBvGRSyDq/Tf
X7zUojiIsr8xgdnHYZCXfCcdPIKU2qnJvYvnvWZPai4TT+4TU0qDhbe26q5klqmX
IC+YHuqUoeoaPHayKY2THurHS90Ex3qmB3LeZ7ngiAZWlEnscRNb+In/DSNXLdFg
9ViW67JOPYnGc5eHGrvVYZP/aIcJgsF6nEykHwf9Lef2dTs26aYZS2+5MV2NqB1z
XdgtA+Jtl+ISTnjvYTn8Zx7tsk4Nu1TrJHsdtCyCbqv4WSJW9eO5T8w1wScMVNRt
BBiQltSG4ZJNAlCb4uXZYxWCZ8mNH9BL8MmWJH4pCOoWOsjZV3Ve0e4IiLnbgyPH
ay0gQ/6vsweCm+vrSu4QIuLysx/yDD84cEOThRyccI8dgxdJc8FERaRu422pfsAS
/0HNh227kM3uqU/Ts/HlNG8jQWMrrr7nKjLA37pzXU9N13Vzu8gIwzyvQz3kMymm
25sxqkb4SifH61KAicjTOIXLQf4UBWlZHnaYTtCsc4BN7e3DmGwNy2Ozm5l7Fb76
Ji5+rVcLxf1UJedmlmruMc+XhvkdoCHuS057MGOb0hG6RpzZFB7/k9lvxFfLbM/B
SnDUvkzxJFk=
=e6ya
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: Fwd: Re: [ox-en] Walther

2004-02-25 Thread Jan Lühr
Greetings,

> or is good code more important than this sort of stuff?

What's the alternativ? Call the CIA or ths Spanish christian inquisition to 
check everybodies political correctness?

Keep smiling
yanosz



Re: Fwd: Re: [ox-en] Walther

2004-02-25 Thread Jan Lühr
Greetings,

> or is good code more important than this sort of stuff?

What's the alternativ? Call the CIA or ths Spanish christian inquisition to 
check everybodies political correctness?

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Tripwire (clone) which would you prefer?

2004-02-23 Thread Jan Lühr
Greetings,

well, I looking for an open source intrusion detection. At first, tripwire 
caputures my attention, but the last open source version seems to be three 
years old - is it still in development or badly vulnerable?
Then I searched for tripwire in the woody packages and found integrit and 
bsign - so which would you prefer and why?
Are there any interesting other projekt that worth looking for?

Keep smiling
yanosz



Tripwire (clone) which would you prefer?

2004-02-23 Thread Jan Lühr
Greetings,

well, I looking for an open source intrusion detection. At first, tripwire 
caputures my attention, but the last open source version seems to be three 
years old - is it still in development or badly vulnerable?
Then I searched for tripwire in the woody packages and found integrit and 
bsign - so which would you prefer and why?
Are there any interesting other projekt that worth looking for?

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-22 Thread Jan Lühr
Greetings,

Am Sonntag, 22. Februar 2004 10:09 schrieb Jim Richardson:
> On Sat, 21 Feb 2004 22:20:05 +0100,
>
>  Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 21, 2004 at 11:09:09AM +0100, Jan L?hr wrote:
> >> Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman:
> >> ..
> >>
> >> > CERT rarely has anything to do with coordinating disclosure, and
> >> > there is no need to bring them into this discussion at all.  The
> >> > coordination that happens is between vendors, like Debian, as
> >> > peers.
> >> >
> >> > Those last two cases are equivalent.  Think about it.
> >>
> >> In the theory of capitalism, competition between vendors is the main
> >> aspect of  going futher in development.
> >
> > Fortunately, Debian isn't driven by capitalism, and we benefit more
> > from cooperation than competition.
>
> Debian competes for users, and just as importantly, developers, it's
> a free market of the mind :)

And it's doing quite well. ;)
My effords to switch a one machine to a current NetBSD or FreeBSD - just for 
testing purpose are not getting concrete ;)

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-22 Thread Jan Lühr
Greetings,

Am Sonntag, 22. Februar 2004 10:09 schrieb Jim Richardson:
> On Sat, 21 Feb 2004 22:20:05 +0100,
>
>  Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> > On Sat, Feb 21, 2004 at 11:09:09AM +0100, Jan L?hr wrote:
> >> Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman:
> >> ..
> >>
> >> > CERT rarely has anything to do with coordinating disclosure, and
> >> > there is no need to bring them into this discussion at all.  The
> >> > coordination that happens is between vendors, like Debian, as
> >> > peers.
> >> >
> >> > Those last two cases are equivalent.  Think about it.
> >>
> >> In the theory of capitalism, competition between vendors is the main
> >> aspect of  going futher in development.
> >
> > Fortunately, Debian isn't driven by capitalism, and we benefit more
> > from cooperation than competition.
>
> Debian competes for users, and just as importantly, developers, it's
> a free market of the mind :)

And it's doing quite well. ;)
My effords to switch a one machine to a current NetBSD or FreeBSD - just for 
testing purpose are not getting concrete ;)

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: output of last

2004-02-21 Thread Jan Lühr
Greetings,...

Am Samstag, 21. Februar 2004 17:11 schrieb s. keeling:
> Incoming from Jan Lühr:
> > Greetings,
> >
> > I discovered some strange output of the last command on our Woody
> > Terminalserver (for X11). I have already posted it on debian-user-german,
> > but I didn't get any answer. (I hope you don't mind, if I post it for the
> > english speaking majority)
> > Although I hope it is not security related, I thing, it may have a
> > security related aspect, which I cannot ignore.
> >
> > At first a run ordinary chkrootkit scan (like I do it every one or two
> > weeks).
>
> Two weeks?  I run it every night.

Well, perhaps I should increase the frequency.

> > This time, it discovered:
> >
> > Checking `wted'... 24 deletion(s) between Thu Jan  1 01:00:00 1970 and
> > Sun Apr 7 02:03:36 1974
>
> Have you checked the chkrootkit archives for anything like this?

Honestly, I had a simular problem with another machine, posted it in may 2002 
and didn't get an answer till know.

> > 17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr  7 02:03:36
> > 1974
>
> Whaat?!?  Between 2004 and 1974?!?

That's my reaction, too.

> > So I renamed all relatedi files in order to start with a non-corrupt
> > database. But what could have caused this corruption? The machine itself
> > is quite stable
>
> Sunspots? 

Maybe, but nothing else was wrong.

> Disk errors?  

Refering to smartmontools, none.

> Resource exhaustion?  

Maybe. This server use non-registered ram. (I know, I already fought my war 
against this machine, but the instiuttion I work is quite incooperativ)

> Unless you can
> definitively nail it down, I wouldn't start worrying until it happens
> again.

Of course - but the server has to keep running. For the next days.
I'll reinstall 'em from scratch if it is a sec issue but I hope it is not - 
maybe there was just a power interrution which left a corrupt databse behind. 
A really don't know.

> > But because of being a valuable information on intruders, intruders or
> > illegal root'ers might have compromised it.
> >
> > What's your opinion?
>
> Can you send logging to another (perhaps dedicated) machine?

Good idea, I have thought of that but it seem to be rather paranoid for me. 
Maybe it is time to realize it.

Keep smiling
yanosz



Re: output of last

2004-02-21 Thread Jan Lühr
Greetings,...

Am Samstag, 21. Februar 2004 17:11 schrieb s. keeling:
> Incoming from Jan Lühr:
> > Greetings,
> >
> > I discovered some strange output of the last command on our Woody
> > Terminalserver (for X11). I have already posted it on debian-user-german,
> > but I didn't get any answer. (I hope you don't mind, if I post it for the
> > english speaking majority)
> > Although I hope it is not security related, I thing, it may have a
> > security related aspect, which I cannot ignore.
> >
> > At first a run ordinary chkrootkit scan (like I do it every one or two
> > weeks).
>
> Two weeks?  I run it every night.

Well, perhaps I should increase the frequency.

> > This time, it discovered:
> >
> > Checking `wted'... 24 deletion(s) between Thu Jan  1 01:00:00 1970 and
> > Sun Apr 7 02:03:36 1974
>
> Have you checked the chkrootkit archives for anything like this?

Honestly, I had a simular problem with another machine, posted it in may 2002 
and didn't get an answer till know.

> > 17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr  7 02:03:36
> > 1974
>
> Whaat?!?  Between 2004 and 1974?!?

That's my reaction, too.

> > So I renamed all relatedi files in order to start with a non-corrupt
> > database. But what could have caused this corruption? The machine itself
> > is quite stable
>
> Sunspots? 

Maybe, but nothing else was wrong.

> Disk errors?  

Refering to smartmontools, none.

> Resource exhaustion?  

Maybe. This server use non-registered ram. (I know, I already fought my war 
against this machine, but the instiuttion I work is quite incooperativ)

> Unless you can
> definitively nail it down, I wouldn't start worrying until it happens
> again.

Of course - but the server has to keep running. For the next days.
I'll reinstall 'em from scratch if it is a sec issue but I hope it is not - 
maybe there was just a power interrution which left a corrupt databse behind. 
A really don't know.

> > But because of being a valuable information on intruders, intruders or
> > illegal root'ers might have compromised it.
> >
> > What's your opinion?
>
> Can you send logging to another (perhaps dedicated) machine?

Good idea, I have thought of that but it seem to be rather paranoid for me. 
Maybe it is time to realize it.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-21 Thread Jan Lühr
Greetings,

Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman:
..

> CERT rarely has anything to do with coordinating disclosure, and there is
> no need to bring them into this discussion at all.  The coordination that
> happens is between vendors, like Debian, as peers.
>
> Those last two cases are equivalent.  Think about it.

In the theory of capitalism, competition between vendors is the main aspect of  
going futher in development.
As in every day capitalism, faster and cheaper is not always better - but if a 
product is well developed and reaches a high quality it might also be better 
- it's the balance that counts.

Thus, won't be a little more competition between the vendors better for 
security at all?
I know, that the flow of information between the vendors is really important 
and should not be stopped - but bigger effords in coding and testing should  
be hounored.

Keep smiling
yanosz



output of last

2004-02-21 Thread Jan Lühr
Greetings,

I discovered some strange output of the last command on our Woody 
Terminalserver (for X11). I have already posted it on debian-user-german, but 
I didn't get any answer. (I hope you don't mind, if I post it for the english 
speaking majority)
Although I hope it is not security related, I thing, it may have a security 
related aspect, which I cannot ignore.

At first a run ordinary chkrootkit scan (like I do it every one or two weeks). 
This time, it discovered:

Checking `wted'... 24 deletion(s) between Thu Jan  1 01:00:00 1970 and Sun Apr  
7 02:03:36 1974
3 deletion(s) between Sun Apr  7 02:03:36 1974 and Tue Feb  3 09:08:53 2004
35 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb  4 09:38:39 2004
13 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb  4 23:41:11 2004
101 deletion(s) between Thu Feb  5 00:02:52 2004 and Wed Mar 25 18:24:58 1970
1 deletion(s) between Wed Mar 25 18:24:58 1970 and Wed Mar 25 18:24:58 1970
8 deletion(s) between Sun Apr  7 02:03:36 1974 and Mon Feb  9 09:01:04 2004
8 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 10:56:08 2004
8 deletion(s) between Tue Feb 10 10:57:03 2004 and Tue Feb 10 12:09:25 2004
1 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 13:40:32 2004
17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr  7 02:03:36 1974
31 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 09:32:27 2004
2 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 11:51:10 2004
2 deletion(s) between Fri Feb 13 11:51:41 2004 and Sat Feb 14 21:11:51 2004
14 deletion(s) between Sun Feb 15 10:19:39 2004 and Sun Apr  7 02:03:36 1974
47 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb 18 14:27:08 2004
19 deletion(s) between Thu Feb 19 00:19:47 2004 and Fri Feb 20 09:28:55 2004
20 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 20 14:09:22 2004

sadly (or luckily ;) no other routing found anything else.
This output is quite strage. While nearly all entries are releated to 2004 
others went back to 1974 or even 1970.
So I suspected a corrupt database and the output of last seem to endorse my 
suspecion.

root pts/2192.168.1.253Fri Feb 20 14:13   still logged in
root pts/1192.168.1.253Fri Feb 20 14:10   still logged in
root pts/1192.168.1.253Fri Feb 20 14:09 - 14:09  (00:00)

Ok, that's correct

rucker:0 [EMAIL PROTECTED]@**   mfelten  Thu Jan  1 01:00   still 
logged in

rucker is neither a computer nor a user and mfelten is a user. Futhermore the 
machine doesn't have an uptime of two months - kernel updates forced the 
machine to be rebooted.

cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0**Thu Jan  1 01:00gone - no logout

These are quite strange entries and there is neither user or machine called 
cal.

h*** h*** rucker:0 Thu Jan  1 01:00gone - no logout

rucker again?!

root pts/1192.168.1.253Thu Feb 19 00:03 - 00:19  (00:16)
root pts/1192.168.1.253Wed Feb 18 23:47 - 23:48  (00:00)
root pts/1alphaWed Feb 18 14:54 - 14:54  (00:00)
root pts/1alphaWed Feb 18 14:27 - 14:45  (00:18)

That's ok.

h*** <***h**@ h***h*** Thu Jan  1 01:00gone - no logout
nt-55.lo [EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  
(00:00)
cal:0**Thu Jan  1 01:00 - 01:00  (00:00)

That's not.

Let's go one.

root pts/1client-64.local  Tue Feb 17 10:29 - 10:29  (00:00)
fatmay   client-50.lo  Tue Feb 17 09:00 - 10:47  (01:46)
swojmon  client-51.lo  Tue Feb 17 08:59 - 10:47  (01:47)
h*** h*** h***h*** Thu Jan  1 0

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-21 Thread Jan Lühr
Greetings,

Am Samstag, 21. Februar 2004 01:10 schrieb Matt Zimmerman:
..

> CERT rarely has anything to do with coordinating disclosure, and there is
> no need to bring them into this discussion at all.  The coordination that
> happens is between vendors, like Debian, as peers.
>
> Those last two cases are equivalent.  Think about it.

In the theory of capitalism, competition between vendors is the main aspect of  
going futher in development.
As in every day capitalism, faster and cheaper is not always better - but if a 
product is well developed and reaches a high quality it might also be better 
- it's the balance that counts.

Thus, won't be a little more competition between the vendors better for 
security at all?
I know, that the flow of information between the vendors is really important 
and should not be stopped - but bigger effords in coding and testing should  
be hounored.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



output of last

2004-02-21 Thread Jan Lühr
Greetings,

I discovered some strange output of the last command on our Woody 
Terminalserver (for X11). I have already posted it on debian-user-german, but 
I didn't get any answer. (I hope you don't mind, if I post it for the english 
speaking majority)
Although I hope it is not security related, I thing, it may have a security 
related aspect, which I cannot ignore.

At first a run ordinary chkrootkit scan (like I do it every one or two weeks). 
This time, it discovered:

Checking `wted'... 24 deletion(s) between Thu Jan  1 01:00:00 1970 and Sun Apr  
7 02:03:36 1974
3 deletion(s) between Sun Apr  7 02:03:36 1974 and Tue Feb  3 09:08:53 2004
35 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb  4 09:38:39 2004
13 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb  4 23:41:11 2004
101 deletion(s) between Thu Feb  5 00:02:52 2004 and Wed Mar 25 18:24:58 1970
1 deletion(s) between Wed Mar 25 18:24:58 1970 and Wed Mar 25 18:24:58 1970
8 deletion(s) between Sun Apr  7 02:03:36 1974 and Mon Feb  9 09:01:04 2004
8 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 10:56:08 2004
8 deletion(s) between Tue Feb 10 10:57:03 2004 and Tue Feb 10 12:09:25 2004
1 deletion(s) between Sun Jan 25 08:20:56 2004 and Tue Feb 10 13:40:32 2004
17 deletion(s) between Sun Jan 25 08:20:56 2004 and Sun Apr  7 02:03:36 1974
31 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 09:32:27 2004
2 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 13 11:51:10 2004
2 deletion(s) between Fri Feb 13 11:51:41 2004 and Sat Feb 14 21:11:51 2004
14 deletion(s) between Sun Feb 15 10:19:39 2004 and Sun Apr  7 02:03:36 1974
47 deletion(s) between Sun Jan 25 08:20:56 2004 and Wed Feb 18 14:27:08 2004
19 deletion(s) between Thu Feb 19 00:19:47 2004 and Fri Feb 20 09:28:55 2004
20 deletion(s) between Sun Jan 25 08:20:56 2004 and Fri Feb 20 14:09:22 2004

sadly (or luckily ;) no other routing found anything else.
This output is quite strage. While nearly all entries are releated to 2004 
others went back to 1974 or even 1970.
So I suspected a corrupt database and the output of last seem to endorse my 
suspecion.

root pts/2192.168.1.253Fri Feb 20 14:13   still logged in
root pts/1192.168.1.253Fri Feb 20 14:10   still logged in
root pts/1192.168.1.253Fri Feb 20 14:09 - 14:09  (00:00)

Ok, that's correct

rucker:0 [EMAIL PROTECTED]@**   mfelten  Thu Jan  1 01:00   still logged in

rucker is neither a computer nor a user and mfelten is a user. Futhermore the 
machine doesn't have an uptime of two months - kernel updates forced the 
machine to be rebooted.

cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0**Thu Jan  1 01:00gone - no logout

These are quite strange entries and there is neither user or machine called 
cal.

h*** h*** rucker:0 Thu Jan  1 01:00gone - no logout

rucker again?!

root pts/1192.168.1.253Thu Feb 19 00:03 - 00:19  (00:16)
root pts/1192.168.1.253Wed Feb 18 23:47 - 23:48  (00:00)
root pts/1alphaWed Feb 18 14:54 - 14:54  (00:00)
root pts/1alphaWed Feb 18 14:27 - 14:45  (00:18)

That's ok.

h*** <***h**@ h***h*** Thu Jan  1 01:00gone - no logout
nt-55.lo [EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0[EMAIL PROTECTED]@**Thu Jan  1 01:00 - 01:00  (00:00)
cal:0**Thu Jan  1 01:00 - 01:00  (00:00)

That's not.

Let's go one.

root pts/1client-64.local  Tue Feb 17 10:29 - 10:29  (00:00)
fatmay   client-50.lo  Tue Feb 17 09:00 - 10:47  (01:46)
swojmon  client-51.lo  Tue Feb 17 08:59 - 10:47  (01:47)
h*** h*** h***h*** Thu Jan  1 01:00 - 01:00  (00

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greeting,.

Am Donnerstag, 19. Februar 2004 15:12 schrieb Florian Weimer:
> Jan Lühr wrote:
> > > You don't.  Tough luck, of course, but that's the price for running
> > > affordable, off-the-shelf software (free or proprietary).
> >
> > well, this might be a reason for using computers in situations we use 'em
> > today.
>
> Probably yes.  If the costs for software production were one or two
> magnitudes higher because only error rates in the range of one error per
> 10 KSLOCS were tolerated by the market, it's unlikely that anybody would
> use free software for its technical merits. 8-)
>
> > I'm just feeling like a helpless person, threadening by a serious
> > disease, who is going to be informened about it, when a cure exists.
> > Trust me, that doesn't feel right.
>
> Large institutions tend to react quite irrational if they are confronted
> with possibly far-reaching defects.  It doesn't matter if a fix is
> available, it's often very expensive to deploy.  The security
> announcement alone can cause significant costs and service disruption.

Well. what about providing binary only package if they are ready.
No debug symbols, no changelog.
Just put a tested fix on the Server, do a quick post like local root exploit 
fixed, CVE id is ... and nothing more.
Thus debian users are able to protect themself and the blackhats would have to 
scan the whole binary in order to speculate for the course.
When the other's have done theirs - release the detailed information.
This might be affordable.

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greeting,.

Am Donnerstag, 19. Februar 2004 15:12 schrieb Florian Weimer:
> Jan Lühr wrote:
> > > You don't.  Tough luck, of course, but that's the price for running
> > > affordable, off-the-shelf software (free or proprietary).
> >
> > well, this might be a reason for using computers in situations we use 'em
> > today.
>
> Probably yes.  If the costs for software production were one or two
> magnitudes higher because only error rates in the range of one error per
> 10 KSLOCS were tolerated by the market, it's unlikely that anybody would
> use free software for its technical merits. 8-)
>
> > I'm just feeling like a helpless person, threadening by a serious
> > disease, who is going to be informened about it, when a cure exists.
> > Trust me, that doesn't feel right.
>
> Large institutions tend to react quite irrational if they are confronted
> with possibly far-reaching defects.  It doesn't matter if a fix is
> available, it's often very expensive to deploy.  The security
> announcement alone can cause significant costs and service disruption.

Well. what about providing binary only package if they are ready.
No debug symbols, no changelog.
Just put a tested fix on the Server, do a quick post like local root exploit 
fixed, CVE id is ... and nothing more.
Thus debian users are able to protect themself and the blackhats would have to 
scan the whole binary in order to speculate for the course.
When the other's have done theirs - release the detailed information.
This might be affordable.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup:
> On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote:
> > On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote:
> > >Yes, this is the norm.  Debian hides security bugs from its users for
> > >extended periods of time.
> >
> > begone, troll
>
> Casting a spell on him won't work either :-), he'll raise his head again
> next time this issue comes up.
>
> Obviously he isn't capable of accepting defeat.

Sorry for trolling. I have been astonished and excited. I hope you forgive me.

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie:
> Jan Lühr wrote:
> > But the dominance of the CERT is excactly the point I'm criticising.
>
> CERT/CC is no longer dominant.  Many people now disclose their findings
> to other coordinators and get paid for that service.  Those who don't
> believe in money don't support CERT/CC either because CERT/CC is selling
> the information they collect via the Internet Security Alliance.

That looks quite chaotic.
Are there (in you opinion) better ways to do so?

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie:
> Jan Lühr wrote:
> > But if knowlegde about this vuln is availeable - if fixes are done, but
> > not avaible yet, how do I protect myself?
>
> You don't.  Tough luck, of course, but that's the price for running
> affordable, off-the-shelf software (free or proprietary).

well, this might be a reason for using computers in situations we use 'em 
today.
I'm just feeling like a helpless person, threadening by a serious disease, who 
is going to be informened about it, when a cure exists.
Trust me, that doesn't feel right.

(Hope to) Keep smiling
yanosz 



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie:
> Jan Lühr wrote:
> > Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
>
> But to what?  Currently, you have two choices: delayed, limited
> disclosure and no disclosure at all.

Please don't take may yesterdays escapades serious, as I posted, I was quite 
stupid in a rude and I apologies for that.

> No vendor currently offers what once was called "full disclosure", even
> in a delayed fashion.
>
> > Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> There's an implicit contract among GNU/Linux distributors: you wait with
> disclosure until most parties are ready.  Red Hat rushed ahead several
> times and the company still has early access to information.  Debian
> would risk to get expelled from the vendor-sec community if it did the
> same, on a more regular scale, I suppose.
>
> > This is exactly the same policy M$ have - but the point is, you could
> > at least inform your users.
>
> Nobody does this, and it could upset users unnecessarily.  There are
> many pitfalls to avoid in this area.  Theo de Raadt's notorious
> disclosure of that OpenSSH bug should serve as a warning to others.

I agree.

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 05:05 schrieb Bernd S. Brentrup:
> On Wed, Feb 18, 2004 at 04:44:15PM -0500, Michael Stone wrote:
> > On Wed, Feb 18, 2004 at 09:17:13PM +0100, Florian Weimer wrote:
> > >Yes, this is the norm.  Debian hides security bugs from its users for
> > >extended periods of time.
> >
> > begone, troll
>
> Casting a spell on him won't work either :-), he'll raise his head again
> next time this issue comes up.
>
> Obviously he isn't capable of accepting defeat.

Sorry for trolling. I have been astonished and excited. I hope you forgive me.

Keep smiling
yanosz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 14:28 schrieben Sie:
> Jan Lühr wrote:
> > But the dominance of the CERT is excactly the point I'm criticising.
>
> CERT/CC is no longer dominant.  Many people now disclose their findings
> to other coordinators and get paid for that service.  Those who don't
> believe in money don't support CERT/CC either because CERT/CC is selling
> the information they collect via the Internet Security Alliance.

That looks quite chaotic.
Are there (in you opinion) better ways to do so?

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 14:24 schrieben Sie:
> Jan Lühr wrote:
> > But if knowlegde about this vuln is availeable - if fixes are done, but
> > not avaible yet, how do I protect myself?
>
> You don't.  Tough luck, of course, but that's the price for running
> affordable, off-the-shelf software (free or proprietary).

well, this might be a reason for using computers in situations we use 'em 
today.
I'm just feeling like a helpless person, threadening by a serious disease, who 
is going to be informened about it, when a cure exists.
Trust me, that doesn't feel right.

(Hope to) Keep smiling
yanosz 


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 14:22 schrieben Sie:
> Jan Lühr wrote:
> > Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
>
> But to what?  Currently, you have two choices: delayed, limited
> disclosure and no disclosure at all.

Please don't take may yesterdays escapades serious, as I posted, I was quite 
stupid in a rude and I apologies for that.

> No vendor currently offers what once was called "full disclosure", even
> in a delayed fashion.
>
> > Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> There's an implicit contract among GNU/Linux distributors: you wait with
> disclosure until most parties are ready.  Red Hat rushed ahead several
> times and the company still has early access to information.  Debian
> would risk to get expelled from the vendor-sec community if it did the
> same, on a more regular scale, I suppose.
>
> > This is exactly the same policy M$ have - but the point is, you could
> > at least inform your users.
>
> Nobody does this, and it could upset users unnecessarily.  There are
> many pitfalls to avoid in this area.  Theo de Raadt's notorious
> disclosure of that OpenSSH bug should serve as a warning to others.

I agree.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 09:39 schrieb Jean Christophe ANDRÉ:
> Le jeudi 19 février 2004 à 09h24 (+0100), Jan Lühr écrivait :
> > What about establishing some kind of warning service? E.g. sshd has a
> > well known serious leak, you should shut it down for the next few days.
>
>   Warning: the Linux kernel has a well known serious leak,
>   you should shut all your servers down for the next few weeks.
>
> Sorry, I couln't resist! ;-)))

;)
I understand - but I rather thought of: mremap bug, wacht out for theses kind 
of processes (wich have to run for quite a long time),

> This is not an easy decision: the alert may alert bad guys too...
>  "Oh! There is some kind vulnerability nobody knows and has
>   corrected in SSH! Let's look for it and use it quick before
>   anybody has been able to patch it!"

Well yeah, but Imho - correct me if I'm wrong, these kind of bad guys, hanging 
all night long in IRC have sources, apart from the official announcements. 
All I'm asking for is getting to know the things they know - not critical 
data use to create exploit, just general information, what is currently 
threadening the security of my system and how I can detect it.

> But this was not the main point of my first mail: I only ask for
> putting some information about the delay in the announcement.
> It will just be usefull (and alertless) for these people (like me)
> checking for the kernel compile time against the announcement date.

I agree.

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,

Am Donnerstag, 19. Februar 2004 09:39 schrieb Jean Christophe ANDRÃ:
> Le jeudi 19 fÃvrier 2004 Ã 09h24 (+0100), Jan LÃhr Ãcrivait :
> > What about establishing some kind of warning service? E.g. sshd has a
> > well known serious leak, you should shut it down for the next few days.
>
>   Warning: the Linux kernel has a well known serious leak,
>   you should shut all your servers down for the next few weeks.
>
> Sorry, I couln't resist! ;-)))

;)
I understand - but I rather thought of: mremap bug, wacht out for theses kind 
of processes (wich have to run for quite a long time),

> This is not an easy decision: the alert may alert bad guys too...
>  "Oh! There is some kind vulnerability nobody knows and has
>   corrected in SSH! Let's look for it and use it quick before
>   anybody has been able to patch it!"

Well yeah, but Imho - correct me if I'm wrong, these kind of bad guys, hanging 
all night long in IRC have sources, apart from the official announcements. 
All I'm asking for is getting to know the things they know - not critical 
data use to create exploit, just general information, what is currently 
threadening the security of my system and how I can detect it.

> But this was not the main point of my first mail: I only ask for
> putting some information about the delay in the announcement.
> It will just be usefull (and alertless) for these people (like me)
> checking for the kernel compile time against the announcement date.

I agree.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone:
> On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote:
> >But if knowlegde about this vuln is availeable - if fixes are done, but
> > not avaible yet, how do I protect myself?
>
> Are you less secure today than yesterday? No. Someone will always know
> about a vulnerability before you do, you need to deal with that. You
> protect yourself by disabling unnecessary services, teaching your users
> good security habits, elminating replayable passwords, keeping good
> logs, reviewing those logs, making good backups, etc. Can you still be
> compromised? Yup. Are there people out there right now exploiting
> vulnerabilities you don't know about? Yup. All you can do is established
> a layered security plan and prepare a disaster recovery plan for the
> inevitable.

Of cours - these are the main aspects of a secure installation, but as we have 
seen in the recent debian compromise it may not be enough.
Imho opinion, please correct me if I'm wrong - an exploit, known for many 
weeks by much people, trying to correct it, is more threadening than some 
exoctic exploit, which may be known to a bunch of people.
Thus the information about the discussed exploit can be easily obtained by  
some "bad guy".
What about establishing some kind of warning service? E.g. sshd has a well 
known serious leak, you should shut it down for the next few days.

Keep smiling
yanosz

P.S. May apologies for my last e-mails - I'm trying not to go on trolling, 
maybe I was to astonished and to excited.
The DST  has done quite a good job for the recent months / yers. Go on!






Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-19 Thread Jan Lühr
Greetings,.

Am Donnerstag, 19. Februar 2004 00:37 schrieb Michael Stone:
> On Wed, Feb 18, 2004 at 11:37:19PM +0100, Jan Lühr wrote:
> >But if knowlegde about this vuln is availeable - if fixes are done, but
> > not avaible yet, how do I protect myself?
>
> Are you less secure today than yesterday? No. Someone will always know
> about a vulnerability before you do, you need to deal with that. You
> protect yourself by disabling unnecessary services, teaching your users
> good security habits, elminating replayable passwords, keeping good
> logs, reviewing those logs, making good backups, etc. Can you still be
> compromised? Yup. Are there people out there right now exploiting
> vulnerabilities you don't know about? Yup. All you can do is established
> a layered security plan and prepare a disaster recovery plan for the
> inevitable.

Of cours - these are the main aspects of a secure installation, but as we have 
seen in the recent debian compromise it may not be enough.
Imho opinion, please correct me if I'm wrong - an exploit, known for many 
weeks by much people, trying to correct it, is more threadening than some 
exoctic exploit, which may be known to a bunch of people.
Thus the information about the discussed exploit can be easily obtained by  
some "bad guy".
What about establishing some kind of warning service? E.g. sshd has a well 
known serious leak, you should shut it down for the next few days.

Keep smiling
yanosz

P.S. May apologies for my last e-mails - I'm trying not to go on trolling, 
maybe I was to astonished and to excited.
The DST  has done quite a good job for the recent months / yers. Go on!





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 18. Februar 2004 22:47 schrieb Michael Stone:
> On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote:
> >Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
>
> Goodbye.
>
> >Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> I don't think anyone in a position to tell you such a thing did so. If
> you want to amuse yourself by wild unfounded speculation that's your
> prerogative, but I have to say that approach is likely to find you
> pissing in the wrong stream.
>
Ok, I thing your are right here.

But if knowlegde about this vuln is availeable - if fixes are done, but not 
avaible yet, how do I protect myself?

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDPpJdAHMQ8GQaYRAQKAZQ//c4YYJ0x5a1k7sN2xj+S8uAoe2tYOFkW4
uUHdEChXnDWHfvs/JiNWItWLUuFcKVSHcYH5v3g3nkGusDLZesrnXH1e6KL7Qu3B
kKElVfpmDhWRVZ8zdUJhKRUa9kwdZZKAMlXC/bYiPqyaIOZCHg0VwXZurcCOanOR
epuJSomXVvL+wL2SIAkg/AbZvhtTEf5cHqoYjnuf4QnGUyPkFEHNz9UuU8XLv7ot
zQjDWCP6b7M4y4XClwOFjeTcGEqUuF/mg9QzDuyw6lZgI9it3XMW6g786uGGY9TT
Ss3DzPNxikuZBxBesH7Q2Ue+UQm9Ym87OQZ6+YYsW/XCIDIE8tyC/N8+elMTr7kh
kYntDX/D0UHwPNagiWdLWoOoibl07EU35z6S891np0Hku0nOhQDP/g6e5vgeqrMN
7VRjEmig/wHCRALh1OiBJGv4FfofZZt8wjr9xZZ66W1/vbpi4LaBv/+MTQoGf1p7
thVY9MSKDbCjKVwMiWRYN5AogoFXR/Gr6Xx1cWzWaveGaIxyAGFNVZ71HLarX0qt
jT4U5cy9Qo0NdtgTHPy9BOWRH4DOyeZMaD+bqdmr1P8OoaZGue/RXq+fzNvgdG29
kpvg0jRVQBpVJQT4JCt2vHOb49twplCC2U4k+E9e50gmD2sqP3qpnHH0P5irmEqP
mgEUYQM7l9c=
=nFoY
-END PGP SIGNATURE-



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,


> > > >> Does this mean, that a well known exploit was kept back for nearly
> > > >> three weeks, just because some odd vendors were unable to build
> > > >> there kernels in time?
> > > >
> > > > Yes, this is the norm.  Debian hides security bugs from its users for
> > > > extended periods of time.
> > >
> > > Yes but this have a reason. Before upload a fix this need be available
> > > in all supported archs and tested since major or users install it
> > > trusting Debian Security Team and 'cause of this, should not fail ;-)
> >
> > Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
> > Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> Take it easy. 

I take security threads serious. Think of beeing avoidable vulnerable for 
nearly three weeks is a pain in my stomach.

>  Maybe you are right, you should switch to another O/S.  I
> bet you they coordinate and delay disclosure as well.  Or better yet,
> you can switch to MS, which you are lucky if you get a patch in 2 weeks
> time.

M$, you are kidding ;)

> Look at it this way:
>
> Debian Security Team (DST) finds out about a security bug from an
> organization (let's say CERT for the sake of discussion).  CERT asks
> Debian to prepare for release but delay disclosure until further notice
> so all the CERT Coordinated Vendors (I believe Debian is one) can get on
> board.  Debian decides to go against CERT and release immediately after
> the fix is made.  CERT then decides they will no longer tell DST in
> advance since they breached trust.  DST then finds out about the
> vulnerability the same time the "rest" of the world does.  DST then
> rushes about (after the announcement) to put together a package and
> release a DSA.  By now they are several hours or a day behind everyone
> else.
>
> Would you still prefer DST ignore coordinated release schedules?  If
> so...perhaps you are correct...you could switch to a different O/S or
> Distro.  Let's see:
>
> RedHatGoing Commercial..hope you have a deep pocket book. (BTW, they
> obey coordinated releases also).
> FedoraStill in it's infancy and organizing from the RedHat break
> off.
> Mandrake...They have Coordinated releases too.
> Any other distrodo they have security releases?

But the dominance of the CERT is excactly the point I'm criticising. Even it 
is necessary to coordinate the sec affords - imho fixies should be applied if 
they are ready and not if some organisation say so.

> Anyhow, please sit back, take a few deep breaths and stop throwing such
> a stink.

ok.

> > May I ask you what local / remote root exploit-fixes are you holding back
> > currently? Should I switch of my sshd for the next few days or does the
> > current bash have an unfixed local root exploit?
>
> Not worth answering

Please don't take it serious - it was meant to be ironic. I beg you pardon, if 
you are insulted by that.

> > This is exactly the same policy M$ have - but the point is, you could at
> > least inform your users.
>
> Yes, inform the users, let the ENTIRE hack community know, don't provide
> a fix.  Then the release coordinator (CERT) gets mad at you...see above.
> How is this any better?

This is not what I'm talking about - unfixed vuln. must be held back.

> > An unknown local root exploit was one of the key parts in the debian
> > server compromise and we have all seen the consequences.
>
> Yes, it was.  There are probably several hundred "unknown local root
> exploits".  The source code is open, why not put your words into action
> and start finding some flaws?

I neither have the knowlegde nor the time for doing that.
But the point at is, that these vuln. are not avoidable at the moment - the 
last has been avoidable for nearly three weeks.

> > Surely, you can see, that I want to keep this risk as small as possible
> > on my servers.
>
> I do also.

well, it seems, that we agreed at last ;)

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq
93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp
aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n
QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S
lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW
I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl
SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe
7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB
r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC
bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X
J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09
BSms9+Cean8=

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
Greetings,

Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador:
> Florian Weimer <[EMAIL PROTECTED]> writes:
> > Jan Lühr wrote:
> >> Does this mean, that a well known exploit was kept back for nearly three
> >> weeks, just because some odd vendors were unable to build there kernels
> >> in time?
> >
> > Yes, this is the norm.  Debian hides security bugs from its users for
> > extended periods of time.
>
> Yes but this have a reason. Before upload a fix this need be available
> in all supported archs and tested since major or users install it
> trusting Debian Security Team and 'cause of this, should not fail ;-)

Well, of course you might have quite good reasons for doing so, but for me, 
this is quite a good reason for changing the distri or os.
Hiding unfixed holes is one thing (and I appreciate that partly) but hiding 
already fixed packages is quite astonishing and you cannot tell me you need 
more than two weeks to test a simple correction.

May I ask you what local / remote root exploit-fixes are you holding back 
currently? Should I switch of my sshd for the next few days or does the 
current bash have an unfixed local root exploit? 
This is exactly the same policy M$ have - but the point is, you could at least 
inform your users.
An unknown local root exploit was one of the key parts in the debian server 
compromise and we have all seen the consequences.
Surely, you can see, that I want to keep this risk as small as possible on my 
servers.

Keep smiling
yanosz



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 18. Februar 2004 22:47 schrieb Michael Stone:
> On Wed, Feb 18, 2004 at 10:36:35PM +0100, Jan Lühr wrote:
> >Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
>
> Goodbye.
>
> >Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> I don't think anyone in a position to tell you such a thing did so. If
> you want to amuse yourself by wild unfounded speculation that's your
> prerogative, but I have to say that approach is likely to find you
> pissing in the wrong stream.
>
Ok, I thing your are right here.

But if knowlegde about this vuln is availeable - if fixes are done, but not 
avaible yet, how do I protect myself?

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDPpJdAHMQ8GQaYRAQKAZQ//c4YYJ0x5a1k7sN2xj+S8uAoe2tYOFkW4
uUHdEChXnDWHfvs/JiNWItWLUuFcKVSHcYH5v3g3nkGusDLZesrnXH1e6KL7Qu3B
kKElVfpmDhWRVZ8zdUJhKRUa9kwdZZKAMlXC/bYiPqyaIOZCHg0VwXZurcCOanOR
epuJSomXVvL+wL2SIAkg/AbZvhtTEf5cHqoYjnuf4QnGUyPkFEHNz9UuU8XLv7ot
zQjDWCP6b7M4y4XClwOFjeTcGEqUuF/mg9QzDuyw6lZgI9it3XMW6g786uGGY9TT
Ss3DzPNxikuZBxBesH7Q2Ue+UQm9Ym87OQZ6+YYsW/XCIDIE8tyC/N8+elMTr7kh
kYntDX/D0UHwPNagiWdLWoOoibl07EU35z6S891np0Hku0nOhQDP/g6e5vgeqrMN
7VRjEmig/wHCRALh1OiBJGv4FfofZZt8wjr9xZZ66W1/vbpi4LaBv/+MTQoGf1p7
thVY9MSKDbCjKVwMiWRYN5AogoFXR/Gr6Xx1cWzWaveGaIxyAGFNVZ71HLarX0qt
jT4U5cy9Qo0NdtgTHPy9BOWRH4DOyeZMaD+bqdmr1P8OoaZGue/RXq+fzNvgdG29
kpvg0jRVQBpVJQT4JCt2vHOb49twplCC2U4k+E9e50gmD2sqP3qpnHH0P5irmEqP
mgEUYQM7l9c=
=nFoY
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,


> > > >> Does this mean, that a well known exploit was kept back for nearly
> > > >> three weeks, just because some odd vendors were unable to build
> > > >> there kernels in time?
> > > >
> > > > Yes, this is the norm.  Debian hides security bugs from its users for
> > > > extended periods of time.
> > >
> > > Yes but this have a reason. Before upload a fix this need be available
> > > in all supported archs and tested since major or users install it
> > > trusting Debian Security Team and 'cause of this, should not fail ;-)
> >
> > Well, of course you might have quite good reasons for doing so, but for
> > me, this is quite a good reason for changing the distri or os.
> > Hiding unfixed holes is one thing (and I appreciate that partly) but
> > hiding already fixed packages is quite astonishing and you cannot tell me
> > you need more than two weeks to test a simple correction.
>
> Take it easy. 

I take security threads serious. Think of beeing avoidable vulnerable for 
nearly three weeks is a pain in my stomach.

>  Maybe you are right, you should switch to another O/S.  I
> bet you they coordinate and delay disclosure as well.  Or better yet,
> you can switch to MS, which you are lucky if you get a patch in 2 weeks
> time.

M$, you are kidding ;)

> Look at it this way:
>
> Debian Security Team (DST) finds out about a security bug from an
> organization (let's say CERT for the sake of discussion).  CERT asks
> Debian to prepare for release but delay disclosure until further notice
> so all the CERT Coordinated Vendors (I believe Debian is one) can get on
> board.  Debian decides to go against CERT and release immediately after
> the fix is made.  CERT then decides they will no longer tell DST in
> advance since they breached trust.  DST then finds out about the
> vulnerability the same time the "rest" of the world does.  DST then
> rushes about (after the announcement) to put together a package and
> release a DSA.  By now they are several hours or a day behind everyone
> else.
>
> Would you still prefer DST ignore coordinated release schedules?  If
> so...perhaps you are correct...you could switch to a different O/S or
> Distro.  Let's see:
>
> RedHatGoing Commercial..hope you have a deep pocket book. (BTW, they
> obey coordinated releases also).
> FedoraStill in it's infancy and organizing from the RedHat break
> off.
> Mandrake...They have Coordinated releases too.
> Any other distrodo they have security releases?

But the dominance of the CERT is excactly the point I'm criticising. Even it 
is necessary to coordinate the sec affords - imho fixies should be applied if 
they are ready and not if some organisation say so.

> Anyhow, please sit back, take a few deep breaths and stop throwing such
> a stink.

ok.

> > May I ask you what local / remote root exploit-fixes are you holding back
> > currently? Should I switch of my sshd for the next few days or does the
> > current bash have an unfixed local root exploit?
>
> Not worth answering

Please don't take it serious - it was meant to be ironic. I beg you pardon, if 
you are insulted by that.

> > This is exactly the same policy M$ have - but the point is, you could at
> > least inform your users.
>
> Yes, inform the users, let the ENTIRE hack community know, don't provide
> a fix.  Then the release coordinator (CERT) gets mad at you...see above.
> How is this any better?

This is not what I'm talking about - unfixed vuln. must be held back.

> > An unknown local root exploit was one of the key parts in the debian
> > server compromise and we have all seen the consequences.
>
> Yes, it was.  There are probably several hundred "unknown local root
> exploits".  The source code is open, why not put your words into action
> and start finding some flaws?

I neither have the knowlegde nor the time for doing that.
But the point at is, that these vuln. are not avoidable at the moment - the 
last has been avoidable for nearly three weeks.

> > Surely, you can see, that I want to keep this risk as small as possible
> > on my servers.
>
> I do also.

well, it seems, that we agreed at last ;)

Keep smiling
yanosz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDPmqNAHMQ8GQaYRAQJRPA//QsTfQrTC4AS6TGwZMQz6mo2t+0TI5Ulq
93bquRnk+mXSYTgOoOC925YJ5O5Vj/9qUMqk8aQq0LQx5g+qOM31vTKRCUBY8XIp
aWuVXiL1iMvncwJGURzyweew0QHb1RYsl7zr9RMZS2M1QwxdfnI2INcevwaBUG3n
QDUnxWAokSxkNMRDlojaFEzzlW3iFauVrzPqr1AfO0+xv78mi6YGxBVvLIWbx/0S
lw0yc2Pm0Cd3YzSFx5tqKortMeTYt1rkiCyPPlq/uCSLoIygtHrII4N/IuBPKFMW
I3xAuNs2cHM92V33Oac4juUs7j35jaQecEZPNKQZ0QPp4pgcSSQ2Mda56/bNC0sl
SzjLJPiVN6akLx4naxssmF2Rw61J/Z9PiEXnwX2/kc6gCs2y4+s5SFY8FKnyIjVe
7tBdilImLMt63CgdRRb332Ji3MNXjmdx8lbyJep0wHvvixslAwhfKjkv0bV/6+lB
r+7c2bQ5uOvWS+TXZg9GCVeuBH2l8tRcWnuN7OWfV7H5XdAWGZ6ewVxgg6Vf2FFC
bgqJ79PMDHFj8/zBmihedefKXu06qGQs/4tCBqQH3xKmgsArmSvsfxLx4CFfB5/X
J6Bt66N2S58ZMkrRp+wiQqkFrI24euAPcHxQLloi2zSYuItilMF3/Stqkedgr/09
BSms9+Cean8=

Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
Greetings,

Am Mittwoch, 18. Februar 2004 21:31 schrieb Otavio Salvador:
> Florian Weimer <[EMAIL PROTECTED]> writes:
> > Jan Lühr wrote:
> >> Does this mean, that a well known exploit was kept back for nearly three
> >> weeks, just because some odd vendors were unable to build there kernels
> >> in time?
> >
> > Yes, this is the norm.  Debian hides security bugs from its users for
> > extended periods of time.
>
> Yes but this have a reason. Before upload a fix this need be available
> in all supported archs and tested since major or users install it
> trusting Debian Security Team and 'cause of this, should not fail ;-)

Well, of course you might have quite good reasons for doing so, but for me, 
this is quite a good reason for changing the distri or os.
Hiding unfixed holes is one thing (and I appreciate that partly) but hiding 
already fixed packages is quite astonishing and you cannot tell me you need 
more than two weeks to test a simple correction.

May I ask you what local / remote root exploit-fixes are you holding back 
currently? Should I switch of my sshd for the next few days or does the 
current bash have an unfixed local root exploit? 
This is exactly the same policy M$ have - but the point is, you could at least 
inform your users.
An unknown local root exploit was one of the key parts in the debian server 
compromise and we have all seen the consequences.
Surely, you can see, that I want to keep this risk as small as possible on my 
servers.

Keep smiling
yanosz


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 18. Februar 2004 19:06 schrieb Steve Kemp:
> On Wed, Feb 18, 2004 at 11:59:06PM +0700, Jean Christophe ANDR? wrote:
> > Does any body could tell me why the /boot/vmlinuz-2.4.18-1-686
> > from kernel-image-2.4.18-1-686 version 2.4.18-12.2 is dated
> > Feb  1 19:53 instead of today???
>
>   The obvious reason is that the kernel was built then, but the DSA
>  wasn't released until now.
>
>   (Maybe for coordination with other vendors, maybe to wait for all
>  the other kernels to be built so there could be a release of them
>  all at the same time).

Does this mean, that a well known exploit was kept back for nearly three 
weeks, just because some odd vendors were unable to build there kernels in 
time?

After the last OpenSSH exploit, I thought that this kind of intransparency is 
limited to OpenBSD, but to what f*** h*** is OpenSource software driving to?
Tranparency is the most important aspect of secure OpenSource Software. 
(Anyway, imho it's the one and only argument for OpenSource software beeing 
morre secure then other.)
What's going on here?

Keep smiling
yanosz

P.S. Please forgive the 4-letter words, but I'm quit excited - I beg your 
pardon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDO0/NAHMQ8GQaYRAQKXNQ//Y/tIRHPHAwYRJomB1B8hyO4cpVQymizn
0VHSMZzD7CfMwo5MF8hR0K9DlQvnLvUSYxC68Ke/BtIhG+Qic7GbLefuv1pCxnrh
p98QsjK//u/M5yw1mRVEiC6zwmCd5yLjqAOt19VBfAHKDiX5ODP4lG3CwPjG8OMR
6kTm593nw26KjJLMFCwkIYrb4Cu+DnMJ88fzKS9DYx1QH4HKkWjZs0uw8KLHo6qh
v5osKWZZm5HJeucp5mCUtsuCEEWr8r3F2M6dlW6KOnxG39hnRhv95hjMaSbgzfJJ
yv/Z+bRLLuCaP9eTLQNZcm/oncvU0riCBn4Sm0+XkxooFvdZB7d63p3itwhLJyjl
A+p5NIflml041QlpS9FZyGetc7djecDQp+nJzUrb2WTQU+XBSV8eWrAvVOeuIwgO
lbG7pVC/J7m+ksQE2ouq7zDqUgL5z4LxLNbu0ARqbzvxnfm8d7Qo+7JGWrkwPEtn
QprqOuDadrN3WoI4TzPyKIJ0rAQRQAWojorwh3srF3AuSxtt41LV5cS08BunNLOH
NYqlu+T49ghoIdM00tnTB9vd9LkIPaFFi0/swFO8NdlYt1hew0SNjVAlBUcgtp7z
vu41qNFtacn1YMgrnJGV3UCr30U4KjbMzlTWPRTOZXKoLEwk0R3TLwWT+Y5jjd43
wXKAXm+uqxw=
=zZqZ
-END PGP SIGNATURE-



Re: DSA 438 - bad server time, bad kernel version or information delayed?

2004-02-18 Thread Jan Lühr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Am Mittwoch, 18. Februar 2004 19:06 schrieb Steve Kemp:
> On Wed, Feb 18, 2004 at 11:59:06PM +0700, Jean Christophe ANDR? wrote:
> > Does any body could tell me why the /boot/vmlinuz-2.4.18-1-686
> > from kernel-image-2.4.18-1-686 version 2.4.18-12.2 is dated
> > Feb  1 19:53 instead of today???
>
>   The obvious reason is that the kernel was built then, but the DSA
>  wasn't released until now.
>
>   (Maybe for coordination with other vendors, maybe to wait for all
>  the other kernels to be built so there could be a release of them
>  all at the same time).

Does this mean, that a well known exploit was kept back for nearly three 
weeks, just because some odd vendors were unable to build there kernels in 
time?

After the last OpenSSH exploit, I thought that this kind of intransparency is 
limited to OpenBSD, but to what f*** h*** is OpenSource software driving to?
Tranparency is the most important aspect of secure OpenSource Software. 
(Anyway, imho it's the one and only argument for OpenSource software beeing 
morre secure then other.)
What's going on here?

Keep smiling
yanosz

P.S. Please forgive the 4-letter words, but I'm quit excited - I beg your 
pardon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iQIVAwUBQDO0/NAHMQ8GQaYRAQKXNQ//Y/tIRHPHAwYRJomB1B8hyO4cpVQymizn
0VHSMZzD7CfMwo5MF8hR0K9DlQvnLvUSYxC68Ke/BtIhG+Qic7GbLefuv1pCxnrh
p98QsjK//u/M5yw1mRVEiC6zwmCd5yLjqAOt19VBfAHKDiX5ODP4lG3CwPjG8OMR
6kTm593nw26KjJLMFCwkIYrb4Cu+DnMJ88fzKS9DYx1QH4HKkWjZs0uw8KLHo6qh
v5osKWZZm5HJeucp5mCUtsuCEEWr8r3F2M6dlW6KOnxG39hnRhv95hjMaSbgzfJJ
yv/Z+bRLLuCaP9eTLQNZcm/oncvU0riCBn4Sm0+XkxooFvdZB7d63p3itwhLJyjl
A+p5NIflml041QlpS9FZyGetc7djecDQp+nJzUrb2WTQU+XBSV8eWrAvVOeuIwgO
lbG7pVC/J7m+ksQE2ouq7zDqUgL5z4LxLNbu0ARqbzvxnfm8d7Qo+7JGWrkwPEtn
QprqOuDadrN3WoI4TzPyKIJ0rAQRQAWojorwh3srF3AuSxtt41LV5cS08BunNLOH
NYqlu+T49ghoIdM00tnTB9vd9LkIPaFFi0/swFO8NdlYt1hew0SNjVAlBUcgtp7z
vu41qNFtacn1YMgrnJGV3UCr30U4KjbMzlTWPRTOZXKoLEwk0R3TLwWT+Y5jjd43
wXKAXm+uqxw=
=zZqZ
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



[OT] Re: Infrastructer back online?

2004-01-10 Thread Jan Lühr
Greetings,

On Sat, Januar 10 2004 at 04:22 Matt Zimmerman wrote:
> On Sat, Jan 10, 2004 at 03:22:15AM +, Nick Boyce wrote:
> > On Wed, 7 Jan 2004 19:43:02 -0800, Matt Zimmerman wrote:
> > >On Thu, Jan 08, 2004 at 04:08:23AM +0100, Martin Helas wrote:
> > >> Am Mi Jan 07, 2004 at 06:5432 -0800 gab Matt Zimmerman <[EMAIL 
> > >> PROTECTED]> 
von sich:
> > >> > On Wed, Jan 07, 2004 at 10:35:30PM +0100, Jan L??hr wrote:
> > >> > > noticing the increasing amount of secure-adv I'd like to ask,
> > >> > > wheter the buid-deamons are back or wheter another issue is
> > >> > > increasing the amount of advs rapidly.
> > >> >
> > >> > Everything is working again.
> > >>
> > >> what's about p.d.o ?
> > >
> > >There is more than one p.d.o and only one of them is not operational. 
> > > That has nothing to do with security, thankfully.
> >
> > Erm .. people.debian.org is back online, though some people seem to be
> > missing from it.  And packages.debian.org is still offline,
>
Any guesses when he is inspected to be only again? Is it going to to take days 
or weeks?

Keep smiling
yanosz



  1   2   >