Re: Debian mirrors and MITM
Kurt Roeckx k...@roeckx.be writes: On Fri, May 30, 2014 at 10:43:56PM +1000, Alfie John wrote: On Fri, May 30, 2014, at 10:24 PM, Michael Stone wrote: On Fri, May 30, 2014 at 10:15:01PM +1000, Alfie John wrote: The public Debian mirrors seem like an obvious target for governments to MITM. I know that the MD5s are also published, but unless you're verifying them with third parties, what's stopping the MD5s being compromised too? The cryptographic signatures that are validated automatically by apt. What's stopping the attacker from serving a compromised apt? apt will check that the new apt is properly signed. This entire secure artifice depends entirely on the integrity of apt, and presumably the various libraries that it depends on. Now I don't want to call into question the esteemed authors of said program, and depending libraries, but I do think that providing https mirrors gives us two distinct advantages over plain http: . in the case that there is a bug in apt, or gpg, or something else, having https would provide at minimum a minor set of defense against bulk, non-targeted quantum insert and foxacid attacks, not to mention MiTM compromises from a hostile local network . keeps an adversary who may be listening on the wire from looking at what you are installing. who cares what you are installing? well it turns out that is very interesting information. If you can see that I've just installed X package, and you then just look over at our security tracker and find that this package has an exploit... micah pgp50ulNq1plS.pgp Description: PGP signature
Re: Bug#605090: Linux 3.2 in wheezy
On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez cor...@debian.org wrote: On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote: On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: (adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: [...] Now, I still think having a hardened Debian kernel inside the distribution is helpful [...] I agree and I would like to see hardening of *all* our configurations, where the performance cost is not too much. That's going to protect all our users rather than just people who seek out a special paranoid configuration. Would you agree that there are some small hardening things that can be done that don't impact performance that much? In particular the privilege boundries mentioned earlier does not seem to introduce any particular performance cost worth worrying about. So I think it's perfectly clear that nor Debian nor Grsecurity are really interested in Debian shipping a Grsecurity kernel. Well, I don't think its fair to say Debian is not interested in shipping a Grsecurity kernel. I think its more accurate to say that the current configuration of the Debian kernel team doesn't find the time to deal with it... but I'm not sure that speaks for all of Debian. I find that sad, because I do think there are users of both which would benefit from that, and not only people who seek out a special paranoid configuration. I agree. On some machines, I would gladly trade perfomance for a hardened kernel where that is more important and it is unfortunate that the attempt to appeal to all possible configurations at the same time results in a kernel that doesn't allow for specialized configurations that people want/need. Anyway, I'll keep updating the current setup for interested people, but without any interest from either party, that definitely looks like a dead end. What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. micah pgpy3qdaRwiBa.pgp Description: PGP signature
Re: Errors when running cron(Debian 6)
On Tue, 17 May 2011 11:39:58 -0300, OLCESE, Marcelo Oscar. molc...@ancal.com.ar wrote: Marcelo Oscar OlceseDear: Upgraded debian 5 to 6 and now I have some mistakes. Know they can be? - Cron Begin Errors when running cron: grandchild #27213 failed with exit status 1: 1 Time(s) Your cronjob returns an exit status 1, previously crond didn't report that, but now it does. Make your cronjob return a zero exit code to make it go away. micah pgp3rjl40HE1X.pgp Description: PGP signature
Re: vserver path leak?
* Karl Goetz k...@kgoetz.id.au [2009-06-11 08:25-0400]: On Wed, 10 Jun 2009 11:05:13 -0400 Micah Anderson mi...@riseup.net wrote: * Karl Goetz k...@kgoetz.id.au [2009-06-10 03:44-0400]: On Tue, 2 Jun 2009 00:14:45 -0400 Micah Anderson mi...@riseup.net wrote: Odd. I've just done it again, using the same two vhosts. (sorry about the wrapping) sidvs:~/debomatic/Debomatic# wesnoth:~# mv /home/vservers/sidvs/root/debomatic /home/vservers/autobuilders/root/ sidvs:~/debomatic/Debomatic# cd .. sidvs:/home/vservers/sidvs/vservers/autobuilders/root/debomatic# wesnoth is the host. Sounds like you have something funny going on in your guest's fstab, either a bind mount or similar... What does your /etc/vservers/sidvs/fstab have in it? wesnoth:~# cat /etc/vservers/sidvs/fstab none /proc procdefaults0 0 none /tmptmpfs size=16m,mode=1777 0 0 none /dev/ptsdevpts gid=5,mode=620 0 0 The autobuilders fstab is the same as that one. Although your fstab looks fine, you have some odd things going on that I'm not sure I totally understand, for example it seems like your vserver root is no longer in /var/lib/vservers, but rather in /home. I think that jumping on the #vserver channel on oftc, or posting to that list will probably get you more debugging advice than I can offer. I'd like to know what is causing this, but I'm having a hard time debugging it because I cannot replicate it with my setup. m signature.asc Description: Digital signature
Re: vserver path leak?
* Karl Goetz k...@kgoetz.id.au [2009-06-10 03:44-0400]: On Tue, 2 Jun 2009 00:14:45 -0400 Micah Anderson mi...@riseup.net wrote: Thanks for your response, sorry about my delay getting back to you. * Karl Goetz k...@kgoetz.id.au [2009-06-01 23:31-0400]: The suggestion in #vserver was if you manage to get a host path on a recent (non broken, i.e. non-debian :) kernel and util-vserver, then it is considered a bug and will be fixed ASAP ... because that basically means that the namespace isolation is not working properly Is this a valid bug? Is there some debianisms involved that could cause the issues, or is it just another upstream who doesnt like unoffical packages? :) Only one way to find out, build a vanilla upstream, with the patch and find out. However, I cannot reproduce what you have seen, using the same kernel. Odd. I've just done it again, using the same two vhosts. (sorry about the wrapping) sidvs:~/debomatic/Debomatic# wesnoth:~# mv /home/vservers/sidvs/root/debomatic /home/vservers/autobuilders/root/ sidvs:~/debomatic/Debomatic# cd .. sidvs:/home/vservers/sidvs/vservers/autobuilders/root/debomatic# wesnoth is the host. Sounds like you have something funny going on in your guest's fstab, either a bind mount or similar... What does your /etc/vservers/sidvs/fstab have in it? micah signature.asc Description: Digital signature
Re: vserver path leak?
* Karl Goetz k...@kgoetz.id.au [2009-06-01 23:31-0400]: The suggestion in #vserver was if you manage to get a host path on a recent (non broken, i.e. non-debian :) kernel and util-vserver, then it is considered a bug and will be fixed ASAP ... because that basically means that the namespace isolation is not working properly Is this a valid bug? Is there some debianisms involved that could cause the issues, or is it just another upstream who doesnt like unoffical packages? :) Only one way to find out, build a vanilla upstream, with the patch and find out. However, I cannot reproduce what you have seen, using the same kernel. micah ps - upstream doesn't like unofficial packages either :) signature.asc Description: Digital signature
Re: Maintaining packages properly
* Steffen Joeris steffen.joe...@skolelinux.de [2009-03-18 18:48-0400]: On Thu, 19 Mar 2009 09:19:28 am Micah Anderson wrote: [snip: removed some unrelated stuff to move discussion to debian-security, please reply there] On a somewhat tangential note, I've been asked a number of times by people why Debian doesn't have security review/auditing of core important packages. These questions have come more frequently after the openssl issue happened (which for some reason people tend to call a 'debacle', why that word was chosen and repeated would be an interesting research project). In OpenBSD they have taken their security audit team (between 6-12 members) and set them on looking for security holes through a process of file-by-file analysis of their critical software components. They determined which elements of the core system are the most critical and have spent a lot of time on reviewing these pieces. This is a process whereby code gets audited and re-audited by different people with different skills over time. Debian has an audit team, but its more of a side-project than a commitment by the project. The OpenBSD security auditing process has succeeded because it was proactive in this approach. I think that the auditing process is not trivial, but it does seem like it would be a good thing for Debian to tighten up in this area. I dont know what packages this would mean, or what this process would entail, but I know we have a team of folks who are commited to auditing in Debian and we just need to bring them closer to the core in some way, without making those core maintainers feel like their work is under suspicion. Not really sure about that one. However, what tends to happen a lot is that fairly new packages are full of security issues. Quite often it is the case that one flaw is detected by chance and then a further audit reveals all sorts of funny things (this just so happens to be the case with a lot of PHP/web stuff). It is impossible to detect all these packages before the release and it should also be a last resort to remove such packages from a stable release. The point I was making was about a small subset of core packages, not the entire archive. I think the entire archive would only ever be done through an automated scanner. Perhaps the subset would be 'essential' plus one or two others that introduce vectors into a system, but which are necessary to access a system and are not 'essential', such as openssh-server. If the set was small enough then in-depth analysis could be done, and on a regular basis. Focusing the efforts of some skilled security auditors on some core Linux programs (even openssh) would benefit more than just Debian as well. However, I do see your point about NEW packages, and it might be interesting, if we could get enough security auditors who had the skills and the time, to be a part of the NEW process. This could introduce an unnecessary delay in the processing of packages, depending on the depth and bredth of such an audit. Or even or a false sense of security if people think that their packages are free of security holes if they've passed NEW. Maybe more people could join the debian security audit team? For a lot of PHP packages it would be enough to check whether certain functions (e.g. htmlspecialchars) are found. If not, this is often an indication of insufficient protection measures. Calling all interested security people who have just been dying to show their skills, or develop stronger auditing skills! micah signature.asc Description: Digital signature
Re: Certification Authorities are recommended to stop using MD5 altogether
On Wed, 31 Dec 2008, Micah Anderson wrote: Does anyone have a legitimate reason to trust any particular Certificate Authority? Yves-Alexis Perez cor...@debian.org writes: I may be wrong, but I trust the CAs in ca-certificates. I've followed the add of French Gvt CA Certificates, and the procedure was enough strict to give me this trust impression. * Russ Allbery r...@debian.org [2009-01-01 10:04-0500]: While this exploit is particularly interesting because it's technical rather than social and therefore easy to wrap one's mind around, it's not been particularly difficult to get a forged certificate since nearly the beginning of the commercial CA concept. Very few of the certificate authorities do any sort of real authentication of the requester, so if you're willing to simple things like fax them forged letterhead, you can probably get a certificate claiming to be just about anyone who isn't extremely high-profile. I agree, and this is why I poised this question. The hierarchical Certificate Authority model is fundamentally flawed, and easily exploited. The state of SSL CAs is really dismal in a number of ways, its trivial to get a certificate issued as someone else, as has been demonstrated by the recent Comodo example, and as Russ explains above. Revocations are handled poorly, if at all, and even the protocols for revocation leak private information about what sites you are visiting to your friendly neighborhood OCSP provider. Firefox/Iceweasel doesn't even ship with a default CRL list for the certificates that are accepted by Mozilla It gets worse trusting a CA means trusting that one central authority is secure, sure their security protocols have been independently audited before they are accepted into Mozilla, but that doesn't mean that they aren't a prime target. Can you imagine the fallout from when a CA is hacked? There are other pressures too. What if the authorities of whatever country the CA resides in decide that they want to snoop the traffic of some site on the internet that has a certificate from the CA? They would just need to get the CA to issue a new certificate that looks like yours and employ a man-in-the middle attack to read all your SSL traffic after installing a proxy somewhere upstream, using this 'replacement' certificate for your server. This proxy is installed between you and the internet, or the target, and the target is presented with the fake certificate instead of yours. With the key in-hand, the attacker can decrypt all encrypted traffic that travels the wire. Unless you are checking the fingerprint of every SSL connection, you will not notice this because the certificate was issued by a trusted CA. To have faith in your SSL certificate, you need to trust the government (not recommended), or trust a company who has various interests, such as commercial and pressures applied to it. In some cases Certificate Authorities are *sold* to someone who wants to buy the company. Purchasing a company, whose root is in Mozilla, would be a great way of compromising a lot of very sensitive data and probably would recoup the investment in no time. Do you trust the United States government, the NSA to have a convenient backdoor into your SSL verified encrypted traffic? What about the company Verisign? They provide a 3rd party CALEA compliance service, which means that they have NSA/FBI backdoors built-into their systems. Chances are AOL, wells fargo, comodo, entrust, equifax, gte, starfieldtech, godaddy, visa, valicert, hungarian company netlock, the Taiwanese government, SwissComm all have similar issues. The architecture and protocols involved here need to be tweaked just a to change the situation so that this problem will no longer exist[0]. The Monkeysphere[1] project's broader goals are to make these sorts of changes, and move us towards a decentralized web-of-trust model, instead of depending on centralized hierarchical models of control. Currently the project only works for SSH connections, but there is work ongoing to make gnutls changes that will eventually lead us to a way out of this dismal situation. If you are interested, the project could use help. micah 0. http://lair.fifthhorseman.net/~dkg/tls-centralization/ 1. http://monkeysphere.info signature.asc Description: Digital signature
Re: Certification Authorities are recommended to stop using MD5 altogether
* bgr...@toplitzer.net bgr...@toplitzer.net [2008-12-31 05:47-0500]: On Mittwoch, 31. Dezember 2008, Cristian Ionescu-Idbohrn wrote: http://www.win.tue.nl/hashclash/rogue-ca/ Could some skilled person comment on the article? I noticed around 20 certificates distributed with the package ca-certificates have Signature Algorithm: md5WithRSAEncryption. Reason to worry? It is a problem. It's a reason to worry. But it is only one of many. (They mentioned that in their presentation: It's a matter of trust :-) ) Don't trust certificates too much. Does anyone have a legitimate reason to trust any particular Certificate Authority? micah signature.asc Description: Digital signature
Re: What to do about SSH brute force attempts?
* Michael Tautschnig [EMAIL PROTECTED] [2008-08-21 07:35-0400]: Hi all, since two days (approx.) I'm seeing an extremely high number of apparently coordinated (well, at least they are trying the same list of usernames) brute force attempts from IP addresses spread all over the world. I've got denyhosts and an additional iptables based firewall solution in place to mitigate these since quite some time already and this seems to do the trick in terms of blocking them fairly quickly. I hope you are aware that its very trivial for a non-privileged user on your system to issue a logger command to trigger a denyhosts DOS to lock out anyone they want. micah signature.asc Description: Digital signature
Re: What to do about SSH brute force attempts?
* Jakov Sosic [EMAIL PROTECTED] [2008-08-21 09:11-0400]: On Thursday 21 August 2008 16:57:27 Max Zimmermann wrote: The problem with reporting the IPs is, that it can become a very big task, as the number of IPs denyhosts blocks increases. You can always write a script that will send an email after every SSH bruteforce attack to a mail address from whois database. That way you don't have to do it manually, and still you can do some good deed if someone has a server that's broken into, and is not (yet) aware of that. You could use dronebl, a dnsbl service, to check against and report attacks to (http://headcandy.org/rojo/ for some examples using fail2ban). micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What to do about SSH brute force attempts?
* Michael Tautschnig [EMAIL PROTECTED] [2008-08-21 09:24-0400]: * Michael Tautschnig [EMAIL PROTECTED] [2008-08-21 07:35-0400]: Hi all, since two days (approx.) I'm seeing an extremely high number of apparently coordinated (well, at least they are trying the same list of usernames) brute force attempts from IP addresses spread all over the world. I've got denyhosts and an additional iptables based firewall solution in place to mitigate these since quite some time already and this seems to do the trick in terms of blocking them fairly quickly. I hope you are aware that its very trivial for a non-privileged user on your system to issue a logger command to trigger a denyhosts DOS to lock out anyone they want. Hmm, no, not really - how would that work? fail2ban and denyhosts watch log files for repeat failed ssh authentication attempts from particular ips. Its quite trivial for a non-privileged user to add entries to your logfiles using the syslog facilities (try it yourself using 'logger'). You will quickly find that you can very simply craft a log message that would be picked up by these programs and be able to block an IP of your choosing. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Study: Attacks on package managers (inclusing apt)
* Michael Stone [EMAIL PROTECTED] [2008-07-17 08:09-0400]: On Thu, Jul 17, 2008 at 04:46:54PM +0200, Daniel Leidert wrote: Today there were some news about a study from the University of Arizona regarding security issues with package management systems (like apt). I did not yet read the whole study, but probably it's interesting for the project (they write about vulnerabilities). The study is here: It doesn't appear that they had a firm grasp of how package distribution actually works in debian, at least. Mostly it seems like oversensationalized attention-grabbing. The relevant point for Debian seems to be limited to the issue that man-in-the-middle attacks are easily done against http://security.debian.org because those mirrors are not using HTTPS. Although PGP-signed Release file prevent tampering with files, the attack doesn't require tampering with files or tampering with signed release files. If I were to MitM security.debian.org, I could provide an outdated (yet properly signed) mirror of the security packages to you. I would simply supply, via a MitM, a mirror that was not updated, so that the packages you were getting were valid and signed. They just are out-dated, so that you would not receive critical security upgrades. Correlating the package skew, with known DSAs that had been released would eventually result in the right remotely exploitable root hole. The simple solution for this would be to require https for security.debian.org. As these machines are run by 'trusted' parties, simply stopping the MitM attack through authenticated https connections would suffice. Following on that attack is the fact that its easy to join the mirror network and once you are in, you can do the same thing as above and keep your mirror a day or four out of date, so that people who use your mirror aren't getting updates for issues that enter through the normal channels. You also have a list of IPs that use your mirror that don't have these updates. There are some (IMHO) less interesting attacks they detail, such as convincing apt to download 18,000,000 TB, but I think the more problematic attacks are the previous ones. It seems worthwhile to examine these issues and make some determinations about what steps (if any) Debian can do to mitigate some of these attacks. signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
* Wolfgang Jeltsch [EMAIL PROTECTED] [2008-07-09 13:31-0400]: configure it to only listen on 127.0.0.1, How do I do this? dpkg-reconfigure doesn’t help. I think the bind9 package comes configured this way by default in Debian (a caching-only local nameserver). Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-1571 and GSSAPI
* Joey Hess [EMAIL PROTECTED] [2008-05-15 09:57-0400]: Juha Jäykkä wrote: Just count how many times you've used GPG over one of the weak links... Zero! Zero gpg invocations over network links! This is Just to Say I have invoked gpg over the network links and which was probably not secure in the least Forgive me it was convenient so sweet and so easy micah --- with apologies to william carlos williams -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1571-1] vulnerability of past SSH/SSL sessions
* Simon Valiquette [EMAIL PROTECTED] [2008-05-14 16:36-0400]: Affected keys include SSH keys [...] and session keys used in SSL/TLS connections. It seems that people are insisting quite a lot on the bad keys, but what worry me a lot more is that, apparently and very logically, past ssh connections and any SSL session keys are to be considered compromised. In other words, if a vulnerable key have been involved, and if someone was able to intercept and save the encrypted data, he/she can now decipher It, whether It is passwords, ssh sessions, secure pop/smtp sessions, ssl tunnels or even database transactions. So you need to change every passwords at risk (bothersome, but relatively easy), but also consider that secure/confidential information, including credit card transactions or whatever, have been disclosed, which is a much bigger problem. SSH traffic cannot be compromised that way. Basically the encryption key used for the SSH session is *not* the host key nor the client key itself, but it is created on session initiation using a Diffie-Helman key exchange and the host/client keys are just used to verify the authenticity of the server. In other words, ssh sessions are not compromised just because an adversary has the host keys (unless a MITM is setup, in which case you need bot the host key and the authentication key to perform a mitm attack). micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Squid Proxy Cache Security Update Advisory SQUID-2007:2
* Stefan Novak [EMAIL PROTECTED] [071212 01:39]: Hello! http://www.squid-cache.org/Advisories/SQUID-2007_2.txt This is CVE-2007-6239[1]. Will there be a patch für Debian Etch? Etch and Sarge are vulnerable, the issue is known to the squid maintainer and the security team[2]. 1. http://security-tracker.debian.net/tracker/CVE-2007-6239 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=455910 signature.asc Description: Digital signature
Re: BIND 9 security update
* Florian Weimer [EMAIL PROTECTED] [070725 01:36]: Will there be a timely security update for BIND 9, or does it make sene to roll your own? There is a security update for this issue being put together since yesterday, its in the testing phase now. Speaking of this issue... this problem existed before in BIND[1] as the old way of doing things was to have sequential 'sequence numbers', these were used to 'authenticate' responses and due to them being sequential they were easily guessed. The fix was to change the sequence numbers to be randomized. However, the field is only 16 bits and so now someone has found a way to predict the sequence numbers again (likely by looking at the algorithm used). Even so, the sequence numbers are not that difficult to predict because you can guess all 2^16 of them at the same time. This real problem in the DNS protocol at a very basic level. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: an issue with recent security advisories
You are missing: deb http://security.debian.org/ etch/updates main micah Tomasz Ciolek wrote: Hi All have packages for these updates: [DSA 1308-1] New iceweasel packages [DSA 1309-1] New PostgreSQL 8.1 [DSA 1310-1] New libexif packages been uploaded to the repositories and added to Releases and Packages files? The reason I ask is that for the past 72 hours my apt tells me there is nothign to be updated, but I am running older version of postgresql and an older version of iceweasel... Whats the point of making a security advisory if the packages are NOT AVAILABLE in mirrors and repositories here is my sources.list... maybe I have some misconfiguraion ? deb ftp://ftp.au.debian.org/debian/ etch main contrib non-free deb ftp://ftp.au.debian.org/debian-security/ etch/updates main contrib non-free deb http://volatile.debian.net/debian-volatile/ etch/volatile main contrib non-free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 1193-1] New XFree86 packages fix several vulnerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin B McCarty ([EMAIL PROTECTED]) wrote: Did the announcement for DSA 1193-1 cause Thunderbird to crash for anyone else? (I was reading it in Thunderbird 1.5.0.7 on Mac OS X with the Enigmail extension installed, so it may not happen on a Debian system. If it does happen, however, someone ought to report a bug.) best regards, Strangely enough, it did for me as well, I thought it was just a fluke until I read your message. I'm running 1.5.0.7-2 with 2:0.94-4 of enigmail installed on a sid system. I was able to open it the second time. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFLGtx9n4qXRzy1ioRAscIAJ9yit4nDbeEWU1Zy6VIJJGPJsNnxACePreu ySJpV18udhVkQmaJyPJb/qE= =axFK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptable: --seconds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gerhard Kroder wrote: Hi, i want to stop sshd account testing by scripties witht the followoing iptables/bash script, but it won't do what i thougt. On a sarge test host with 2 aliased nic (eth0:1 and eth0:2), this script loads correctly, it drops connections with --hitcount 3 correctly (client gets timeout, sshd gets no connection/log), but doesn't get back for login after --seconds 120. No error or logging, only Connection timed out when i try to ssh into that aliased interfaces. login on eth0 always works ok. Unfortunately the ipt_recent netfilter maintainer is no longer fixing bugs in this module and there are several known problems which are outstanding. The upstream Netfilter people intend to mark this module as BROKEN or EXPERIMENTAL in 2.6.16 if a new maintainer is not found[1]. This is unfortunate, because this is an fun solution to this problem. Hopefully it will get fixed soon. micah 1.http://lists.netfilter.org/pipermail/netfilter-devel/2005-December/022696.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDnE149n4qXRzy1ioRArhPAKCYEU/SKwwRfzljT27Kz1uSi1k0BACfT7WO Uc7QncTDIWsd30sySzyusBg= =SBsq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is a security bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Stone wrote: On Wed, Nov 23, 2005 at 10:53:46PM -0800, Thomas Bushnell BSG wrote: In the case of galeon, for example, there is no bug, because it can restart with the old state. Of course, if there's a page that causes the browswer to crash repeatedly, won't it just crash when it restarts? Yep, thats why Galeon gives you the option to save your previous tabs into a bookmark group, or to restore it before it starts loading crashed tabs. This way if you have a site that is causing a crash you can edit out that bookmark, then open that bookmark group in separate tabs and be back to normal. The sane way Galeon manages crashes is the reason why I don't use Firefox. Yes it has a tab-browser extention that is supposed to do this, but my last exploration into the exciting random world of extentions for firefox showed me that this extention was highly inadequite comparably. micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDhf5A9n4qXRzy1ioRAj4vAJ9R0LkrGvVTbEawGHI/RGZGwCeqsACgqjTe OkN+3cUQZD2ecy6RgnEanAQ= =5ln7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Sorry for the email with the maligned from address in that last message (debian-security@lists.debian.org), I'm trying out mozilla-thunderbird with a virtual identity extention that seems to construct odd from lines, that message was not from debian-security@lists.debian.org, so don't take it as such. micah On Sun, 31 Jul 2005, Micah wrote: Nikita V. Youshchenko wrote: There won't be _any_ Debian solution with the current mozilla.org policy. Not exactly. Correct statement is, '... with the current mozilla.org policy AND Debian traditional way of doing things'. I agree with this statement. I see the problem. The question is - how to solve it. Mozilla.org policy is probably out of our control. However, our way of doing things is not. Is Mozilla.org policy out of our control? If there was enough pressure on them to provided isolated security fixes they might actually do it. Perhaps they don't have any clue that this is a major issue for some of the largest linux distributions, and if they knew it was they might devote some energy towards being more friendly to their neighbors. Has anyone any definitive information, or is it just speculation? Has anyone actually spoken to people at Mozilla.org about this problem? micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security - action
Alvin Oga schrieb am Tuesday, den 28. June 2005: On Tue, 28 Jun 2005, Micah Anderson wrote: Alvin Oga schrieb am Tuesday, den 28. June 2005: If you are interested in testing security, then there is a group working on this project. Here is some information about the history of the team, and if you read through the message there is information about how to help: http://lists.debian.org/debian-devel-announce/2005/03/msg00014.html saw that before ... and no response ... so i let it die, the assumption being, that people looking for helpers will reply to those volunteering, but i guess one has to pass the screeners requirements before getting onto the next level You sent an email where about what and got no response? I did not see your offer to help come across the mailing list (if it is there, can you point out the URL to the message?)... Often people looking for helpers are needing helpers because they are so busy that they need people who are wanting to help to take initiative, rather than be hand-held. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security - action
Alvin Oga schrieb am Wednesday, den 29. June 2005: On Wed, 29 Jun 2005, Micah Anderson wrote: Alvin Oga schrieb am Tuesday, den 28. June 2005: You sent an email where about what and got no response? I did not see your offer to help come across the mailing list (if it is there, can you point out the URL to the message?)... i think you can search thru the debian security archives just as easily as i can or in fact even more easily since yu have a debian acct ?? Did you read the email that I referenced? It doesn't sound like you did. in either case, it doesnt matter to me if people reply or not to those that are volunteering - i go on the assumption that people get selected based on the merits or pecking order or friends of friends or ?? whatever the criteria is .. The testing-security team is not operating this way. - from this last batch of emails about security, i saw there was a bunch of folks willing to help do security work .. and i'm hoping somebody takes up the volunteer's offerings and unload some tasks or do some other forms of methodology tests I sent a message whose contents detail how to get involved in the testing-security team for those who wish to volunteer. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bad press related to (missing) Debian security - action
Alvin Oga schrieb am Wednesday, den 29. June 2005: On Wed, 29 Jun 2005, Micah Anderson wrote: i think you can search thru the debian security archives just as easily as i can or in fact even more easily since yu have a debian acct ?? Did you read the email that I referenced? It doesn't sound like you did. this is precisely why volunteers disappear I'm sorry I dont understand. Volunteers disappear because they read a message detailing how to volunteer and then don't follow those directions and then disappear? If someone wants to volunteer, then they need to do the things that are detailed about how to get involved, otherwise they are disappearing themselves. I do not understand, the directions are clear, and I reproduce them and the referenced URLs below: Any with a interest in participating are welcome to join the team, Debian Developers and others with the skills and desire to help. The team can be contacted through its mailing list[14]. There is a second mailing list[15] that receives commit messages to our repository. An alioth project page[1] is also available. Have a read of this message[16] if you are interested in participating, the details are there about how to start helping check CANs on a regular basis. http://lists.alioth.debian.org/mailman/listinfo/secure-testing-team http://lists.alioth.debian.org/mailman/listinfo/secure-testing-commits http://secure-testing.alioth.debian.org/ http://lists.debian.org/debian-security/2004/10/msg00166.html I note that there is no message from you found on the secure-testing-team mailing list. I am unable to find your alioth account, did you sign up for one? Did you email the secure-testing alioth project administrator to be added to the project? Did you check out the svn repository? of course i read it ... the first yime you posted and the 2nd time when you sent the same url again .. multiple times for how to volunteer Please, where in the details about how to volunteer did you get stuck so we can improve them? somehow, magically, volunteers can become overnight experts and no handholding is needed at all or who is doing what You do not need to be an expert, but you do need to be able to follow directions that are detailed for you, if directions do not make sense, ask and they will be cleared up. How magic do you want the process? i think there has been enough about emails in here.. and since no proactive direction is being made, i think i'll bow out of volunteering again .. but will gladly help later when things are more organized and its clear what the benefits of volunteering hundred of hrs/month would be The benefits of volunteering are also detailed in that email. What sort of proactive direction are you expecting? I think you have it backwards, the proactivity needs to come from you. You are right that the group is still in its infancy in terms of being organized, but how do you expect it to become organized? The only way it will become organized in a volunteer organization is if the volunteers (read: this can be you), proactively organize it. If you wish to wait until everyone else has done the work to organize the group, and then you want to come in and do something you may find that the group is organized a way that you do not like and you will regret that you did not help organize it the way you like. Micah signature.asc Description: Digital signature
Re: Bad press related to (missing) Debian security - action
Alvin Oga schrieb am Tuesday, den 28. June 2005: [snip] etch/testing where are the security patches ?? - i want it to also have latest apps i care about ( latest kernels, latest apache, latest xxx, .. ) - this is the parts i'm interested in structuring for security updates as some/most security patches are fixed in later releases from the originating authors/sites and they already maintain and keep their eyes on all the announced vulnerabilities and exploits If you are interested in testing security, then there is a group working on this project. Here is some information about the history of the team, and if you read through the message there is information about how to help: http://lists.debian.org/debian-devel-announce/2005/03/msg00014.html micah signature.asc Description: Digital signature
Re: bid 12877, apache mod_ssl remote DoS
The way you can tell is to get the debian source of apache, look at the patch referenced via those URLs and see if it has been applied to the debian source. If it has been, then the problem has been resolved in Debian. If it hasn't been, then either the problem is unknown and you should file a bug against apache (tagging it security), and providing as much information as you can. Or the problem does not affect the particular version of apache in Debian... Do your absolute best to figure out the latter first. Micah On Wed, 30 Mar 2005, Geoff Crompton wrote: Does anyone know if apache 1.3 is affected by the issue mentioned at http://www.securityfocus.com/bid/12877 Also, anyone know how Debian stands with this? -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-0210, kernel netfilter dos memory leak
Fixed in 2.6.8-15 (see #300838) Things that show up in that list are unresolved items, if it doesn't show up there then it is resolved. Micah On Wed, 30 Mar 2005, Geoff Crompton wrote: On http://merkel.debian.org/~joeyh/testing-security.html this CAN is listed, as waiting for a 2.4.27-9 to fix this issue. The securityfocus article says that this is a 2.6.8 issue. Does anyone know if a fix for this has made it into a 2.6.8 debian kernel? -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-0448 and #286905, dsa?
I think that the best course of action with regards to this query is to send a message to [EMAIL PROTECTED] asking this very question. The maintainers of this package are probably not paying attention to debian-security, but would respond to this query. Although the bug has been closed, by sending a message there, it will become re-opened. Micah On Thu, 17 Mar 2005, Geoff Crompton wrote: I noticed that #286905 fixes CAN-2005-0448, however it fixes it for version 5.8.4-7, while stable has perl version 5.6.1-8.8. #286905 is marked as resolved, will this fix be backported to stable, and a DSA released? It is indicated that straight 5.6.1 is affected by this issue at http://www.securityfocus.com/bid/12767. -- Geoff Crompton Debian System Administrator Strategic Data +61 3 9340 9000 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CAN-2005-0448 and #286905, dsa?
On Thu, 17 Mar 2005, Micah Anderson wrote: I think that the best course of action with regards to this query is to send a message to [EMAIL PROTECTED] asking this very question. The maintainers of this package are probably not paying attention to debian-security, but would respond to this query. Although the bug has been closed, by sending a message there, it will become re-opened. Note: the last sentence of the above is wrong, only a reopen command to control reopens, sending a message just extends the time until the bug is archived (restting the counter to 28 days again). Other bug systems I work with do it that way, I was confused. I have re-opened the bug and tagged it as woody. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xpdf vulnerability?
On Wed, 16 Mar 2005, Frank Küster wrote:
Frank Küster [EMAIL PROTECTED] wrote:
Micah Anderson [EMAIL PROTECTED] wrote:
7. Is our xpdf vulnerable to CAN-2005-0206[13]?
This also needs to be checked for pdftex (in tetex-bin) and pdftohtml,
and perhaps others that include xpdf code.
Can anybody point me to a place where I can find the patch for the
64-bit-specific issue? The CVE only lists the RedHat and Mandrake
security announcements, but I don't know how to get those source-rpm's.
I found ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.00pl3.patch - if that's the
right one, tetex-bin in sarge/unstable is vulnerable. In woody the code
looks very different.
Unfortunately, it takes some deep digging sometimes. I've had to email
the security announce mailing address to find specific patches before.
Surprisingly, they responded...
I searched Redhat's Bugzilla, and found this:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135393
Apparantly this patch:
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=110599
plus the following missing hunk:
@@ -186,6 +192,11 @@
}
if (start = pagesSize) {
pagesSize += 32;
+if (pagesSize*(int)sizeof(Page *)/sizeof(Page *) != pagesSize ||
+pagesSize*(int)sizeof(Ref)/sizeof(Ref) != pagesSize) {
+ error(-1, Invalid 'pagesSize' parameter.);
+ goto err3;
+}
Can you determine if tetex-bin, pdftohtml and xpdf have this in Sarge?
Micah
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bits from the Testing Security team
[ note: Reply-To: set to debian-devel ] This is a quick summary of the Debian Testing Security Team[1] work and a request for some aid to help sort out some difficult Sarge security problems. Contents of this message: What the Testing Security Team has been up to How can I leverage my powerful brain to aid you? Let the games begin! This is fun, how else can I help? Background information -- The first thing the Debian Testing Security Team did was to check all security holes since the release of Debian 3.0 to ensure that all the holes are fixed in Sarge. Now that this has finished, we are busy checking to make sure that security problems that have already been fixed in unstable as well as stable do not continue to affect testing. We are also dealing with new holes as they are made known. Every day we get an updated list of Mitre's comprehensive list of known security problems, known affectionatly as CAN numbers[2]. We've been going through old CANs as well as the newly released CANs and check changelogs, advisories, test proof-of-conecpts, dig out patches from other vendor's kernels, whatever is needed to confidently determine whether sarge is vulnerable to the particular CAN or not. We then record our findings, file bugs, write patches, do NMUs as necessary, track fixed packages and work with the Debian Release Managers to make sure fixes reach testing quickly. The result of this is the Testing Security issues page[2] which shows how many holes are unfixed (that we know of) in testing as well as the associated bugs and debian package versions required to plug the hole. In addition to this, it also indicates how many unprocessed TODO items are still remaining for us to process.[4] How can I leverage my powerful brain to aid you? I'm glad you asked! Your brain is much bigger than our individual brains, so we need the collective help of everyone to brainstorm solutions to some difficult remaining CANs. Our goal is to reduce our TODO count to zero, but we need your help. There are a few CANs that are pretty vague in their broad applicability, they potentially cover a number of packages and we need help figuring out which packages those would be. Bonus points if you can tell us if the package is affected by its associated CAN, extra bonus points if you tell us the bug number that you filed to alert the package maintainer of the security hole, tagged it security and added a patch. So without further ado, here they are, if you have any information that can help us, please follow-up to debian-devel. Let the games begin! 1. What packages contain X.400 (CAN-2003-0565)[5]? 2. What packages contain S/MIME besides mozilla, because the current version (mozilla 2:1.7.3) contains safe NSS 3.9.1 (CAN-2003-0564)[6]? 3. What packages modify JPEG images (CAN-2005-0406)[7]? Please limit your answers to those packages that do not modify the EXIF thumbnail, we dont need to hear imagemagick or the gimp. If you use this jpg[8] whose thumbnail contains a green swirl instead of the red one you can test this. Basically if the file is loaded into a program doing the right thing (e.g. gimp) and saved again, the swirl in the thumbnail turns red. If a program is doing the wrong thing (e.g. convert[9]), the thumbnail stays green. convert exiftest.jpg -draw rectangle 0,0 300,300 fill black out.jpg will draw a black rectangle over the swirl, but the thumbnail in out.jpg still has the green swirl. 4. What packages contain libtiff code (besides libtiff4 3.6.1-4 which is not affected due to DSA-617-1)? (CAN-2004-1308)[10]? 5. What ftp programs are affected by directory traversal vulnerabilities (CAN-2002-1345)[11]? 6. What packages in Debian are SMTP mailscanners that can be potentially bypassed by fragmenting messages (CAN-2002-1121)[12]. 7. Is our xpdf vulnerable to CAN-2005-0206[13]? This is fun, how else can I help? - Glad you asked! Any with a interest in participating are welcome to join the team, Debian Developers and others with the skills and desire to help. The team can be contacted through its mailing list[14]. There is a second mailing list[15] that receives commit messages to our repository. An alioth project page[1] is also available. Have a read of this message[16] if you are interested in participating, the details are there about how to start helping check CANs on a regular basis. What do I win? huh? Huh?! - You get a little sticker that says: I donated to Sarge today! [swirl here] Ok, not really, but you do get our gratitude, these are annoying and difficult. Thanks. [1] http://secure-testing.alioth.debian.org/ [2] http://cve.mitre.org/cve/candidates/downloads/full-can.html [3] http://merkel.debian.org/~joeyh/testing-security.html [4] An alternate page tracks archive changes more quickly, but may be inaccurate due to bugs
Re: using sarge on production machines
Marc Haber schrieb am Friday, den 18. February 2005: On Fri, Feb 18, 2005 at 04:40:56AM -0800, Harry wrote: --- Marc Haber [EMAIL PROTECTED] wrote: What does this gain you? A compomised uml is as bad as a compromised system. Nice idea. However, if somebody roots one of the UML installation, that somebody can probably escape out of the UML and gain user privileges on the host system and then use one of the numerous kernel vulnerabilities (I have long lost track of them) to escalate to root on the host system. I am quite sceptical about using UML to allow security flaws in UMLled system components. Have a look at vservers (http://linux-vserver.org/), designed specifically to fix the problems that can be circumvented with chroots, take up significantly less resources than UMLs, and are really quite cool. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ph.unimelb.edu.au #1012] AutoReply: [SECURITY] [DSA 674-1] New mailman packages fix several vulnerabilities
Hello, Thank you for providing this entire list with a trouble ticket through your poorly setup request tracker software, it is nice to know we have two of these today because we know you are on top of things and will get back to us as soon as you can. These are obviously very important announcements to you and your organization and you want to make sure someone follows up on them, but I don't think the rest of the list needs to know that. Please do us all a favor and turn off your auto-responder. Micah On Thu, 10 Feb 2005, Physics IT Support via RT wrote: Hello, Thank you for submitting your IT support request to School of Physics IT Support. Request ID: [ph.unimelb.edu.au #1012] Request Title: [SECURITY] [DSA 674-1] New mailman packages fix several vulnerabilities You will shortly receive another email indicating who will deal with your request. Ideally additional enquiries or information about your request should be sent to us by responding to this email. However, please feel free to phone the person allocated to your request if you wish to discuss your request further. Please also feel free to visit us between 11-1 if you want to talk face to face with us. Thank you, [EMAIL PROTECTED] - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Debian Security Advisory DSA 674-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze February 10th, 2005 http://www.debian.org/security/faq - -- Package: mailman Vulnerability : cross-site scripting, directory traversal Problem-Type : remote Debian-specific: no CVE ID : CAN-2004-1177 CAN-2005-0202 Two security related problems have been discovered in mailman, web-based GNU mailing list manager. The Common Vulnerabilities and Exposures project identifies the following problems: CAN-2004-1177 Florian Weimer discovered a cross-site scripting vulnerability in mailman's automatically generated error messages. An attacker could craft an URL containing JavaScript (or other content embedded into HTML) which triggered a mailman error page that would include the malicious code verbatim. CAN-2005-0202 Several listmasters have noticed unauthorised access to archives of private lists and the list configuration itself, including the users passwords. Administrators are advised to check the webserver logfiles for requests that contain /./ and the path to the archives or cofiguration. This does only seem to affect installations running on web servers that do not strip slashes, such as Apache 1.3. For the stable distribution (woody) these problems have been fixed in version 2.0.11-1woody9. For the unstable distribution (sid) these problems have been fixed in version 2.1.5-6. We recommend that you upgrade your mailman package. Upgrade Instructions - wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 3.0 alias woody - Source archives: http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9.dsc Size/MD5 checksum: 595 774821799ef4968703a7e44ed9bbf648 http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9.diff.gz Size/MD5 checksum:32974 3987fa82ba9a2fe22f0a8f131acbca33 http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11.orig.tar.gz Size/MD5 checksum: 415129 915264cb1ac8d7b78ea9eff3ba38ee04 Alpha architecture: http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9_alpha.deb Size/MD5 checksum: 461524 5080358514f761e483b13fb4e369847a ARM architecture: http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9_arm.deb Size/MD5 checksum: 459168 7c5ed235d7c1520f08a98a4f39d0a9bf Intel IA-32 architecture: http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9_i386.deb Size/MD5 checksum: 452242 cbde3d89ad2f09776c1f498f22858919 Intel IA-64 architecture: http://security.debian.org/pool/updates/main/m/mailman/mailman_2.0.11-1woody9_ia64.deb Size/MD5 checksum: 462126 eb6151c02a2992afd21a6e04fecd75a5 HP
Official security support for sarge
According to [EMAIL PROTECTED] message posted by Steve Langasek on Mon, 2 Aug 2004 00:11:55: Aug. 8: Official security support for sarge begins Anyone have any updates on this? Is it happening, is it delayed, what can we do to help? micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice needed, trying to find the vulnerable code on Debian webserver.
On Tue, 15 Jun 2004, Alvin Oga wrote: hi ya On Wed, 16 Jun 2004, TiM wrote: Look at installing mod_security, http://modsecurity.org Install some rules for it to harden your webserver, see if anything is flagged in the security log. other web server testing tools http://www.linux-sec.net/Web/#Testing Has anyone actually used any of these to find the vulnerabilities that are being discussed? A lot of what is listed on this page are commercial offerings, so I haven't tried them, but a couple I did try against a site that was having similar problems, and I couldn't get any of them to find the problem that is being discussed here. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advice needed, trying to find the vulnerable code on Debian webserver.
On Tue, 15 Jun 2004, Alvin Oga wrote: hi ya On Wed, 16 Jun 2004, TiM wrote: Look at installing mod_security, http://modsecurity.org Install some rules for it to harden your webserver, see if anything is flagged in the security log. other web server testing tools http://www.linux-sec.net/Web/#Testing Has anyone actually used any of these to find the vulnerabilities that are being discussed? A lot of what is listed on this page are commercial offerings, so I haven't tried them, but a couple I did try against a site that was having similar problems, and I couldn't get any of them to find the problem that is being discussed here. micah
Re: password managers
Try kedpm, its a debian package, and has console as well as GUI support and uses the FPM data, really nice. micah On Tue, 15 Jun 2004, Kenneth Jacker wrote: al what does everyone else use to keep track of all there passwords? I've used 'tkpasman' for years ... nice! http://www.xs4all.nl/~wbsoft/linux/tkpasman.html -- Prof Kenneth H Jacker [EMAIL PROTECTED] Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: password managers
Try kedpm, its a debian package, and has console as well as GUI support and uses the FPM data, really nice. micah On Tue, 15 Jun 2004, Kenneth Jacker wrote: al what does everyone else use to keep track of all there passwords? I've used 'tkpasman' for years ... nice! http://www.xs4all.nl/~wbsoft/linux/tkpasman.html -- Prof Kenneth H Jacker [EMAIL PROTECTED] Computer Science Dept www.cs.appstate.edu/~khj Appalachian State Univ Boone, NC 28608 USA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody Backport of tripwire
Yes, Tripwire is GPLd, if you dont mind the March 3, 2001 version. Their commercial version is much newer however micha On Thu, 22 Apr 2004, Noah Meyerhans wrote: On Fri, Apr 23, 2004 at 02:48:33AM +0200, Marcin Orda wrote: I've got tripwire packages that I use internally at work. They're built for woody, and I'd be happy to share them with anybody who's interested. They aren't in any way based on the tripwire packages from unstable, so I don't know how they compare, but we're using them on our production servers, so they're certainly of reasonably good quality. Grab the .debs from http://debian.csail.mit.edu/pub/csail-debian/dists/woody/csail/ And why do people continue to believe that tripwire is non-free? Seriously, tripwire is free. It is licensed under the GPL. See http://www.tripwire.org/ or http://www.sourceforge.net/projects/tripwire/ noah micah Naturally, the common people don't want war, but after all, it is the leaders of a country who determine the policy...Voice or no voice, the people can always be brought to the bidding of the leaders. This is easy. All you have to do is to tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Goering, Nuremburg trial
Security holes in 2.4.25?
With the rash of security gaffs in the kernel related to mmap and mremap, does it make anyone else nervous to see the following in the changelog for 2.4.26: o mremap NULL pointer dereference fix If this was a security concern, would it be noted in the changelog? Additionally, the 2.4.25 kernel seems to have a local root exploit for CDROMs: http://lwn.net/Articles/80480/ micah Naturally, the common people don't want war, but after all, it is the leaders of a country who determine the policy...Voice or no voice, the people can always be brought to the bidding of the leaders. This is easy. All you have to do is to tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Goering, Nuremburg trial signature.asc Description: Digital signature
Web software security scanners
Hey all, I am looking for some scanners which look for known vulnerabilities in different web software. I have a collegue who runs a community web server with some 100 different sites and almost half that in different CMS', blogs, publishing software, formmail scripts, postnuke, phpnuke, drupal, moveable type, etc. They have unfortunately allowed their people to install whatever software they want, which has resulted in this hodgepodge of random software, at different versions (not all debian packages) and some of these pieces of software have some exploitable holes in them. This is known because he has found script kiddies who have been able to upload tar.gz files as user www-data into /tmp /var/tmp and /home/www-data and then extract them and run them. This has resulted in shells being started as www-data, and scripted attempts to escalate priviledges using lkm, mremap, and other kernel holes (which haver never, to his knowledge, worked because he maintains the latest kernel and watches his filesystem with aide and sees the rogue processess started almost immediately and they get killed, but there is still the possibility of course). Anyways, he is rebuilding the machine, as he should, with much more strict web hosting security considerations in mind, but he still would like to track down which piece of software is vulnerable. Based on the data that I have gone over for him, it is pretty plain that someone is using some sort of vulnerability scanner to find that he is running a phpnuke (for eg.) that is vulnerable, and then running an exploit on it. The attacks are with out a doubt scripted. He has run nessus on the system, but nessus only really gives you false positives about software that is installed that isn't the right version (because the debian packages actually backport the security fixes), but it doenst know anything about the different CMS' etc. Does anyone know of these types of scanners? Thanks!
Re: have the compromized debian servers been cleaned?
They are clean. On Fri, 05 Dec 2003, Mo Zhen Guang wrote: Hi, I am going to install a few new debian servers, but I worry about the integratity of the packages because of the incident of compromised debian servers some days ago. Can anybody confirm me if these servers are clean now? Thank you Mo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: have the compromized debian servers been cleaned?
They are clean. On Fri, 05 Dec 2003, Mo Zhen Guang wrote: Hi, I am going to install a few new debian servers, but I worry about the integratity of the packages because of the incident of compromised debian servers some days ago. Can anybody confirm me if these servers are clean now? Thank you Mo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-403-1] userland can access Linux kernel memory
I want to chime in here also, I too was unhappy that I did not know about a local root exploit in 2.4.22 until the Debian machines were compromised in this manner. I think a lot of people were in the same boat (not to mention the debian folks). I watch kerneltrap, kernel traffic, and slashdot fairly regularly for these purposes, and I did not see anything of this sort come through, otherwise I would have patched immediately (which is what I did last night when I received the information). Previous kernel security holes have been treated with a lot more transparancy and communication than this one was, I am disappointed that this one wasn't. I understand that the transfer of the guard was going on between 2.4.22 and 2.4.23 to a new maintainer, which might have caused this. This is not a Debian problem, IMHO, but a kernel development issue, and I would like to know how I can be more abreast of future security issues like this if Bugtraq (et. al), kerneltrap, kerneltraffic, slashdot, etc. are not notified to flag this, and kernel.org does not flag this on the website, are we to wait for some high profile exploit to happen again before we are alerted to this problem? Unfortuantely, complaining about it here isn't going to help, but I solicit other's comprehension of the matter to better identify the best way to address this problem. Should something be sent to the linux-kernel development list from A group of concerned Debian users or should we individually troll the list complaining about this and not doing anything? ;) micah On Tue, 02 Dec 2003, Adam ENDRODI wrote: Just a humble question: how the average user who doesn't use the kernel sources provided by Debian and cannot follow lk should have known about the bug? The changelog read ``Add TASK_SIZE check to do_brk()'', there's no indication that it's a security fix. I'm really curious how you cope with it. bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-403-1] userland can access Linux kernel memory
On Tue, 02 Dec 2003, Michael Stone wrote: On Tue, Dec 02, 2003 at 01:35:51PM -0600, Micah Anderson wrote: I want to chime in here also, I too was unhappy that I did not know about a local root exploit in 2.4.22 until the Debian machines were compromised in this manner. I think a lot of people were in the same boat (not to mention the debian folks). I watch kerneltrap, kernel traffic, and slashdot fairly regularly for these purposes, and I did not see anything of this sort come through, otherwise I would have patched immediately (which is what I did last night when I received the information). What do you want? It was a mistake. It happens. Deal with it. If people had realized it was an exploit it would have been dealt with differently. I was lead to believe that it was a known exploit in the kernel, based on what you say above I may be wrong. If so, then I would definately change my tune. I dont expect people to announce security holes if they don't know about them. micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-403-1] userland can access Linux kernel memory
On Tue, 02 Dec 2003, Rick Moen wrote: Quoting Micah Anderson ([EMAIL PROTECTED]): I want to chime in here also, I too was unhappy that I did not know about a local root exploit in 2.4.22 until the Debian machines were compromised in this manner. I think a lot of people were in the same boat (not to mention the debian folks). I watch kerneltrap, kernel traffic, and slashdot fairly regularly for these purposes, and I did not see anything of this sort come through, otherwise I would have patched immediately (which is what I did last night when I received the information). [...] I would like to know how I can be more abreast of future security issues like this if Bugtraq (et. al), kerneltrap, kerneltraffic, slashdot, etc. are not notified to flag this, and kernel.org does not flag this on the website, are we to wait for some high profile exploit to happen again before we are alerted to this problem? Well, the kernel.org changelogs _are_ public. Feel free to read them on an ongoing basis, and comment on the security implications of bugfixes as they're entered into the BitKeeper repository. There are any number of mailing lists, Web sites, and magazines that would be delighted to publish your analyses and advisories. My information was flawed, I was told that the kernel developers knew that this was a security hole back in September. The fact that this was actually, NOT KNOWN, makes my searches in vain make sense. I see know from the detailed analysis that just came out: The attacker then retrieved the source code through HTTP for an (at that time) unknown local kernel exploit and gained root permissions via this exploit. So, hey, my bad. Or I guess you could pay someone to do likewise. anyways... micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA-403-1] userland can access Linux kernel memory
I want to chime in here also, I too was unhappy that I did not know about a local root exploit in 2.4.22 until the Debian machines were compromised in this manner. I think a lot of people were in the same boat (not to mention the debian folks). I watch kerneltrap, kernel traffic, and slashdot fairly regularly for these purposes, and I did not see anything of this sort come through, otherwise I would have patched immediately (which is what I did last night when I received the information). Previous kernel security holes have been treated with a lot more transparancy and communication than this one was, I am disappointed that this one wasn't. I understand that the transfer of the guard was going on between 2.4.22 and 2.4.23 to a new maintainer, which might have caused this. This is not a Debian problem, IMHO, but a kernel development issue, and I would like to know how I can be more abreast of future security issues like this if Bugtraq (et. al), kerneltrap, kerneltraffic, slashdot, etc. are not notified to flag this, and kernel.org does not flag this on the website, are we to wait for some high profile exploit to happen again before we are alerted to this problem? Unfortuantely, complaining about it here isn't going to help, but I solicit other's comprehension of the matter to better identify the best way to address this problem. Should something be sent to the linux-kernel development list from A group of concerned Debian users or should we individually troll the list complaining about this and not doing anything? ;) micah On Tue, 02 Dec 2003, Adam ENDRODI wrote: Just a humble question: how the average user who doesn't use the kernel sources provided by Debian and cannot follow lk should have known about the bug? The changelog read ``Add TASK_SIZE check to do_brk()'', there's no indication that it's a security fix. I'm really curious how you cope with it. bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://www.keyserver.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
Try the package falselogin micah Javier Fern?ndez-Sanguino Pe?a schrieb am Thursday, den 23. October 2003: On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: Hi We recently noticed that a stock woody install produces an /etc/passwd in which most, if not all, system users have a valid shell entry of /bin/sh. They're all unable to login due to having no valid password, but best UNIX security practice typically involves giving accounts that don't need to be able to login a shell of /bin/false or /bin/true. Other distros (at least some of them) appear to follow suit. I have meant to ask this question for some time too. Specially since some distributions (such as RedHat) provide system users with a /bin/noshell shell. I'm not sure if this is the same shell as the one provided by Titan [1] but IMHO I believe it's a must to have a shell that logs the entry attempt to syslog (as opposed to what /bin/false or /bin/true do). So, anybody knows any issues (Debian specific or not) related to using /bin/noshell instead? Regards Javi PS: I guess, as for recommended practice, you mean CERT's guidelines: http://www.cert.org/security-improvement/implementations/i049.02.html which does suggest using Titan's noshell [1] Titan's noshell can be found at: http://www.fish.com/titan/src1/noshell.c pgp0.pgp Description: PGP signature
Re: Why not use /bin/noshell? (was Re: Why do system users have valid shells)
Try the package falselogin micah Javier Fern?ndez-Sanguino Pe?a schrieb am Thursday, den 23. October 2003: On Wed, Oct 22, 2003 at 09:45:24AM +0200, Tobias Reckhard wrote: Hi We recently noticed that a stock woody install produces an /etc/passwd in which most, if not all, system users have a valid shell entry of /bin/sh. They're all unable to login due to having no valid password, but best UNIX security practice typically involves giving accounts that don't need to be able to login a shell of /bin/false or /bin/true. Other distros (at least some of them) appear to follow suit. I have meant to ask this question for some time too. Specially since some distributions (such as RedHat) provide system users with a /bin/noshell shell. I'm not sure if this is the same shell as the one provided by Titan [1] but IMHO I believe it's a must to have a shell that logs the entry attempt to syslog (as opposed to what /bin/false or /bin/true do). So, anybody knows any issues (Debian specific or not) related to using /bin/noshell instead? Regards Javi PS: I guess, as for recommended practice, you mean CERT's guidelines: http://www.cert.org/security-improvement/implementations/i049.02.html which does suggest using Titan's noshell [1] Titan's noshell can be found at: http://www.fish.com/titan/src1/noshell.c pgp208hc7G1Ft.pgp Description: PGP signature
Re: logcheck thinks that system is under attack, related to ssl problem?
Pretty exciting... is there any place that we can track the progress of this? I'm very interested to make an assessment of what is going on to determine if I should just patch the existing logcheck so that it stops sending me attack alerts, or if I should wait for this overhaul to come out. Thanks! micah Steve Kemp schrieb am Tuesday, den 07. October 2003: On Tue, Oct 07, 2003 at 09:52:59AM +0200, Alain Tesio wrote: I had exactly the same problem, it's because logcheck look for cracking patterns before removing lines which should be ignored, it shouldn't be hard to fix. logcheck is in the middle of a major overhaul by myself and the former maintainer, which is why it looks like much hasn't changed with it for the past few weeks. Months? :( There's a new project in the process of being finalised using Alioth to host it, and things should start to get better with in quickly once it's up and running. .. right now I'm just waiting for the SVN repository to be created so that the history can be imported. Steve -- # Debian Security Audit Project http://www.steve.org.uk/Debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: logcheck thinks that system is under attack, related to ssl problem?
Pretty exciting... is there any place that we can track the progress of this? I'm very interested to make an assessment of what is going on to determine if I should just patch the existing logcheck so that it stops sending me attack alerts, or if I should wait for this overhaul to come out. Thanks! micah Steve Kemp schrieb am Tuesday, den 07. October 2003: On Tue, Oct 07, 2003 at 09:52:59AM +0200, Alain Tesio wrote: I had exactly the same problem, it's because logcheck look for cracking patterns before removing lines which should be ignored, it shouldn't be hard to fix. logcheck is in the middle of a major overhaul by myself and the former maintainer, which is why it looks like much hasn't changed with it for the past few weeks. Months? :( There's a new project in the process of being finalised using Alioth to host it, and things should start to get better with in quickly once it's up and running. .. right now I'm just waiting for the SVN repository to be created so that the history can be imported. Steve -- # Debian Security Audit Project http://www.steve.org.uk/Debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: logcheck thinks that system is under attack, related to ssl problem?
On Mon, 06 Oct 2003, Noah L. Meyerhans wrote: You don't have much evidence that it's a security issue at this point. Logcheck's active system attack messages rarely indicate such a thing. Don't do anything drastic like reinstall the system until you've got better evidence that you've been cracked. In this case, I doubt you have. Speaking of which, has anyone found a way to configure the active system attack key words? There is a user on my system whose email has the word attacK' in it so that triggers logcheck, and I've tried every different exclusion file and regexp there is to make it ignore it, but I can't so I get a logcheck email everytime this guy gets or sends an email. Its gotten to the point that logcheck is becoming totally useless (ie. I wont read them because I put little value in the information that they contain). I've tried searching the web, and contacting the package maintainer, but no results. Thanks, micah pgp0.pgp Description: PGP signature
Re: logcheck thinks that system is under attack, related to ssl problem?
On Mon, 06 Oct 2003, Noah L. Meyerhans wrote: You don't have much evidence that it's a security issue at this point. Logcheck's active system attack messages rarely indicate such a thing. Don't do anything drastic like reinstall the system until you've got better evidence that you've been cracked. In this case, I doubt you have. Speaking of which, has anyone found a way to configure the active system attack key words? There is a user on my system whose email has the word attacK' in it so that triggers logcheck, and I've tried every different exclusion file and regexp there is to make it ignore it, but I can't so I get a logcheck email everytime this guy gets or sends an email. Its gotten to the point that logcheck is becoming totally useless (ie. I wont read them because I put little value in the information that they contain). I've tried searching the web, and contacting the package maintainer, but no results. Thanks, micah pgpaGKEe3owA6.pgp Description: PGP signature
Re: Man-db problem
This is not a security issue, as far as I can tell. Take a look at /etc/cron.daily/man-db and see what it does. You will see something like this: # regenerate man database if [ -x /usr/bin/mandb ]; then # --pidfile /dev/null so it always starts; mandb isn't really a # but we want to start it like one. start-stop-daemon --start --pidfile /dev/null \ --startas /usr/bin/mandb --oknodo --chuid man \ -- --no-purge --quiet fi Run this on the command line, as root, without the --quiet option, and you will see errors that might need to be fixed. This same thing happened to me, after a couple crashes and fscks messed up some of my man directory so some manpages.1.gz were turned into directories, or just plain mush. I had to remove those completely to get the man-db regeneration to work, and would have to be reinstalled from the original packages that they came from in order to get the man pages properly returned. micah On Fri, 15 Aug 2003, Per Tenggren wrote: Hey! I updateed my Woody a few days ago and every night I receive the following mail from Cron: Subject: Cron [EMAIL PROTECTED] test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily Message: run-parts: /etc/cron.daily/man-db exited with return code 3 I never had this problem before update! Regards Per -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Man-db problem
This is not a security issue, as far as I can tell. Take a look at /etc/cron.daily/man-db and see what it does. You will see something like this: # regenerate man database if [ -x /usr/bin/mandb ]; then # --pidfile /dev/null so it always starts; mandb isn't really a # but we want to start it like one. start-stop-daemon --start --pidfile /dev/null \ --startas /usr/bin/mandb --oknodo --chuid man \ -- --no-purge --quiet fi Run this on the command line, as root, without the --quiet option, and you will see errors that might need to be fixed. This same thing happened to me, after a couple crashes and fscks messed up some of my man directory so some manpages.1.gz were turned into directories, or just plain mush. I had to remove those completely to get the man-db regeneration to work, and would have to be reinstalled from the original packages that they came from in order to get the man pages properly returned. micah On Fri, 15 Aug 2003, Per Tenggren wrote: Hey! I updateed my Woody a few days ago and every night I receive the following mail from Cron: Subject: Cron [EMAIL PROTECTED] test -e /usr/sbin/anacron || run-parts --report /etc/cron.daily Message: run-parts: /etc/cron.daily/man-db exited with return code 3 I never had this problem before update! Regards Per -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Mon, 14 Jan 2002, Daniel Polombo wrote: Adam Warner wrote: Well, maybe you should follow Tim's advice and go check the security team's FAQ : Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. Of course, if you're using unstable, fixes tend to appear quickly, but : - tend to is not acceptable when security is concerned - it may take a lot more time depending on your local mirror As woody draws closer and closer to being stable, and potato draws closer and closer to the legendary dinosaurs which roamed the earth with regards to its outdated software, perhaps this comittment to woody's security could be revisted. I would be surprised if a lot of the criticsm that is coming out on this issue is not related to the fact that a lot of people have moved from potato to woody because they cannot continue to use potato due to the requirements of certain software or underlying libraries, and are thus burned by this security policy. Lets face it, potato has some ancient software that is getting outdated, you can hardly find any software that uses db2 anymore, and it is not trivial to backport from db3, the version of perl makes usage and installation of anything that was done in the last 5 years difficult... potato is great, if you want to only use the packages which come with it, it is great as a server which doesn't need any changes, but if you want to do anything semi-new, or outside of the package scope, you have to move to woody, or just wait. With that movement comes a significant loss in security policy. Now that woody draws near to being stable, perhaps the policy can be altered to accomodate for that. Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian security being trashed in Linux Today comments
On Mon, 14 Jan 2002, Daniel Polombo wrote: Adam Warner wrote: Well, maybe you should follow Tim's advice and go check the security team's FAQ : Q: How is security handled for testing and unstable? A: The short answer is: it's not. Testing and unstable are rapidly moving targets and the security team does not have the resources needed to properly support those. If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. Of course, if you're using unstable, fixes tend to appear quickly, but : - tend to is not acceptable when security is concerned - it may take a lot more time depending on your local mirror As woody draws closer and closer to being stable, and potato draws closer and closer to the legendary dinosaurs which roamed the earth with regards to its outdated software, perhaps this comittment to woody's security could be revisted. I would be surprised if a lot of the criticsm that is coming out on this issue is not related to the fact that a lot of people have moved from potato to woody because they cannot continue to use potato due to the requirements of certain software or underlying libraries, and are thus burned by this security policy. Lets face it, potato has some ancient software that is getting outdated, you can hardly find any software that uses db2 anymore, and it is not trivial to backport from db3, the version of perl makes usage and installation of anything that was done in the last 5 years difficult... potato is great, if you want to only use the packages which come with it, it is great as a server which doesn't need any changes, but if you want to do anything semi-new, or outside of the package scope, you have to move to woody, or just wait. With that movement comes a significant loss in security policy. Now that woody draws near to being stable, perhaps the policy can be altered to accomodate for that. Micah
Re: poppassd
Potato has 1.2-14 as its latest for poppasswd... I agree that v1.8-ceti would be a better solution, especially considering the security issues you cited. What does it take to get this version into the security updates? A bug filed? Micah On Wed, 09 Jan 2002, Steve Mickeler wrote: I'm using poppassd v1.8-ceti from http://www.ceti.com.pl/~kravietz/prog.html It doesnt suffer from any of the problems you described below. 1) I cant use an old password, only the current password will work to change the password 2) It is PAM aware 3) It supports MD5 I also make sure that my users change their password via an https form to step up the security between the client and server. If you look at the poppassd-1.8-ceti source, its nice and clean and has some handy configuration options such as #define POP_MIN_UID /* minimum UID which is allowed to change This is handy to make sure that uid 0 doesnt get its password changed by some clown who thinks this could be fun. Maybe debian ought to investigate using the -ceti branch of poppassd. On Wed, 9 Jan 2002, martin f krafft wrote: alright, my users don't know how to do shell, and they can't change passwords. now, i just upgraded to squirrelmail (upgraded because i had IMP before, barf!), which has a plugin to change the password. it's TLS encrypted, so not too much of a problem, but in testing out poppassd, the underlying password changing daemon (usually used for Eudora), i have just fainted: (assume johndoe's password is mypw, and he changes to mypw2) 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw 200 your new password please. newpass mypw2 200 Password changed, thank you. quit 200 Bye. all good up to here: madduck@seamus:~ su johndoe Password:enter mypw su: Authentication failure Sorry. madduck@seamus:~ su johndoe Password:enter myNewpw johndoe@seamus:/home/madduck now sit and chill, we'll just do it again: 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw the old one !!! 200 your new password please. newpass mypw3 200 Password changed, thank you. quit 200 Bye. poppassd asks for the password, but it seemingly doesn't care!!! sure, it runs as root, so it doesn't need it, but it should validate it!!! (and yes, indeed, it *did* change the password.) madduck@seamus:~ su johndoe Password:enter mypw su: Authentication failure Sorry. madduck@seamus:~ su johndoe Password:enter myNewpw su: Authentication failure Sorry. madduck@seamus:~ su johndoe Password:enter myOtherpw johndoe@seamus:/home/madduck it gets better: 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass kjsdgkl a totally random string 200 your new password please. newpass abcabcab 500 Invalid user or password aha. smartie! *but*: (recall that the password is still myOtherpw) 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw2 = *a* previous one 200 your new password please. newpass another 200 Password changed, thank you. quit 200 Bye. and it changed it again... ... which means that even though i bound to localhost only, any local user can change any other one's password, even root's! but it also means that i am confused. the man page and docs say specifically that the proggie uses the passwd binary, and does not edit /etc/shadow by itself. but while johndoe's password was md5 hashed in /etc/shadow before all this happened, look at it now: johndoe:ZmwcDtXWGdpLM:11354:0:9:7::: that's not md5! it's crypt()! moreover, PAM never logged a passwd change, but poppassd logged to /var/log/syslog itself. now all this aside, maybe someone can explain to me the algorithm of poppassd: apparently, it only lets you change your password if the old password you provide with pass is the original or any of the passwords that you had once used through poppassd. if you try other strings for password, poppassd will deny the update. is this an inherent feature of the crypt() hashes, or is something thoroughly screwed up? actually, further testing established that when you change a password mypw to mypw2, both will work, if you then change it to mypw3, all three will work. however, if it starts out as mypw2 md5-hashed, then the other two won't work. i still don't understand it, and yes, the passwords are all 8 characters! if it uses /bin/passwd actually as root,
Re: poppassd
Potato has 1.2-14 as its latest for poppasswd... I agree that v1.8-ceti would be a better solution, especially considering the security issues you cited. What does it take to get this version into the security updates? A bug filed? Micah On Wed, 09 Jan 2002, Steve Mickeler wrote: I'm using poppassd v1.8-ceti from http://www.ceti.com.pl/~kravietz/prog.html It doesnt suffer from any of the problems you described below. 1) I cant use an old password, only the current password will work to change the password 2) It is PAM aware 3) It supports MD5 I also make sure that my users change their password via an https form to step up the security between the client and server. If you look at the poppassd-1.8-ceti source, its nice and clean and has some handy configuration options such as #define POP_MIN_UID /* minimum UID which is allowed to change This is handy to make sure that uid 0 doesnt get its password changed by some clown who thinks this could be fun. Maybe debian ought to investigate using the -ceti branch of poppassd. On Wed, 9 Jan 2002, martin f krafft wrote: alright, my users don't know how to do shell, and they can't change passwords. now, i just upgraded to squirrelmail (upgraded because i had IMP before, barf!), which has a plugin to change the password. it's TLS encrypted, so not too much of a problem, but in testing out poppassd, the underlying password changing daemon (usually used for Eudora), i have just fainted: (assume johndoe's password is mypw, and he changes to mypw2) 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw 200 your new password please. newpass mypw2 200 Password changed, thank you. quit 200 Bye. all good up to here: [EMAIL PROTECTED]:~ su johndoe Password:enter mypw su: Authentication failure Sorry. [EMAIL PROTECTED]:~ su johndoe Password:enter myNewpw [EMAIL PROTECTED]:/home/madduck now sit and chill, we'll just do it again: 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw the old one !!! 200 your new password please. newpass mypw3 200 Password changed, thank you. quit 200 Bye. poppassd asks for the password, but it seemingly doesn't care!!! sure, it runs as root, so it doesn't need it, but it should validate it!!! (and yes, indeed, it *did* change the password.) [EMAIL PROTECTED]:~ su johndoe Password:enter mypw su: Authentication failure Sorry. [EMAIL PROTECTED]:~ su johndoe Password:enter myNewpw su: Authentication failure Sorry. [EMAIL PROTECTED]:~ su johndoe Password:enter myOtherpw [EMAIL PROTECTED]:/home/madduck it gets better: 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass kjsdgkl a totally random string 200 your new password please. newpass abcabcab 500 Invalid user or password aha. smartie! *but*: (recall that the password is still myOtherpw) 200 seamus poppassd v1.2 hello, who are you? user johndoe 200 your password please. pass mypw2 = *a* previous one 200 your new password please. newpass another 200 Password changed, thank you. quit 200 Bye. and it changed it again... ... which means that even though i bound to localhost only, any local user can change any other one's password, even root's! but it also means that i am confused. the man page and docs say specifically that the proggie uses the passwd binary, and does not edit /etc/shadow by itself. but while johndoe's password was md5 hashed in /etc/shadow before all this happened, look at it now: johndoe:ZmwcDtXWGdpLM:11354:0:9:7::: that's not md5! it's crypt()! moreover, PAM never logged a passwd change, but poppassd logged to /var/log/syslog itself. now all this aside, maybe someone can explain to me the algorithm of poppassd: apparently, it only lets you change your password if the old password you provide with pass is the original or any of the passwords that you had once used through poppassd. if you try other strings for password, poppassd will deny the update. is this an inherent feature of the crypt() hashes, or is something thoroughly screwed up? actually, further testing established that when you change a password mypw to mypw2, both will work, if you then change it to mypw3, all three will work. however, if it starts out as mypw2 md5-hashed, then the other two won't work. i still don't understand it, and yes, the passwords are all 8 characters! if it uses /bin/passwd
Re: Root is God? (was: Mutt tmp files)
On Fri, 16 Nov 2001, Mathias Gygax wrote: well, i thought this is the definition of root. no. with LIDS you can protect files and syscalls even from root. in my setup, root cannot even write to his own home directory. No, you can't. No matter how you cut it, root can install a new kernel, sans LIDS and write to his/her home dir. my root user can't write to /usr/*, doesn't have any special syscall access to change network and firewall settings, can't SETUID/SETGID and is really locked like a normal user etc. but... root in this setup is useless. you can't do anything that looks like administration. you can run the daemons that need root access, but they're limited and can't do the full root stuff root usually does. LIDS basically does protect the kernel from root. Nothing can protect the kernel from root if root can replace the kernel. Sure you may have /boot mounted read-only, but that is a simple remount, or boot into single user mode, or put the kernel somewhere else, or physically put in a different harddrive. There is no way, nor any reason why, to setup a system in such a way that the maintainer of the system cannot maintain it. You cannot completely lock out root, for if you do, it is no longer root. Can root physically access the machine? If not, then there is someone else who would be root. Thats like saying root doesn't have the root password. It doesn't matter, root can change the root password. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Root is God? (was: Mutt tmp files)
On Fri, 16 Nov 2001, Mathias Gygax wrote: well, i thought this is the definition of root. no. with LIDS you can protect files and syscalls even from root. in my setup, root cannot even write to his own home directory. No, you can't. No matter how you cut it, root can install a new kernel, sans LIDS and write to his/her home dir. my root user can't write to /usr/*, doesn't have any special syscall access to change network and firewall settings, can't SETUID/SETGID and is really locked like a normal user etc. but... root in this setup is useless. you can't do anything that looks like administration. you can run the daemons that need root access, but they're limited and can't do the full root stuff root usually does. LIDS basically does protect the kernel from root. Nothing can protect the kernel from root if root can replace the kernel. Sure you may have /boot mounted read-only, but that is a simple remount, or boot into single user mode, or put the kernel somewhere else, or physically put in a different harddrive. There is no way, nor any reason why, to setup a system in such a way that the maintainer of the system cannot maintain it. You cannot completely lock out root, for if you do, it is no longer root. Can root physically access the machine? If not, then there is someone else who would be root. Thats like saying root doesn't have the root password. It doesn't matter, root can change the root password.
crc32 compensation attack
Got what appears to be a crc32 compensation attack in my logs today, about 10 minutes worth of these types of messages should I be worried? Should I laugh at this feable attempt to break in? Should I gnaw my fingernails with my shotgun on my lap? Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Sep 23 13:02:05 stallman sshd[650]: Disconnecting: crc32 compensation attack: network attack detected Sep 23 13:02:06 stallman sshd[653]: Disconnecting: crc32 compensation attack: network attack detected Sep 23 13:02:07 stallman sshd[658]: Disconnecting: crc32 compensation attack: network attack detected
crc32 compensation attack
Got what appears to be a crc32 compensation attack in my logs today, about 10 minutes worth of these types of messages should I be worried? Should I laugh at this feable attempt to break in? Should I gnaw my fingernails with my shotgun on my lap? Active System Attack Alerts =-=-=-=-=-=-=-=-=-=-=-=-=-= Sep 23 13:02:05 stallman sshd[650]: Disconnecting: crc32 compensation attack: network attack detected Sep 23 13:02:06 stallman sshd[653]: Disconnecting: crc32 compensation attack: network attack detected Sep 23 13:02:07 stallman sshd[658]: Disconnecting: crc32 compensation attack: network attack detected -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
setuid changes
I was thinking it would be nice to see what sort of new setuid programs show up on my box each day... then I noticed that these are already being logged in /var/log/setuid.today and /var/log/setuid.yesterday. What makes these? It appears they come from /etc/cron.daily/standard which runs /usr/sbin/checksecurity. But, what is the point of logging these each day into /var/log/setuid.changes if nobody sees them? Why doesn't this list get emailed to root? Am I missing something? Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 076-1] New most packages available
Not all mutt users use vi, as a pager I use most, as an editor I use jed. These things can be configured. On Tue, 18 Sep 2001, Andres Salomon wrote: Aside from the fact that it's a pretty big IF; I'm not aware of too many mail clients that use pagers. mutt uses vi, pine uses pico, X based MUAs certainly don't use most.. perhaps mail(x) or something similar use it, but that's not all too common. Certainly not enough, IMO, to classify this as a remote exploit. On Tue, Sep 18, 2001 at 05:01:59PM -0400, Aaron M. Ucko wrote: Andres Salomon [EMAIL PROTECTED] writes: How is this a remote exploit? If I know somebody uses most as a pager for mail, I can send him or her a specially-formatted message which will do various nasty things to his or her account. -- Aaron M. Ucko, KB1CJC [EMAIL PROTECTED] (finger [EMAIL PROTECTED]) -- Any OS is only as good as its admin, and you obviously suck. -- Ian Gulliver, http://orbz.org/mail/mansunix.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared root account
On Mon, 09 Jul 2001, Jason Healy wrote: About the best you can hope for is to log to another machine (so sudoers can't hose your logfiles), and be vigilant about checking what they do. Anyway, to your point about passwords, I say again (do we detect a theme?): use PAM and make them use a different password for sudo. If you want to get real draconian, you can make them use OTP (one-time These both seem like excellent practices, for the clueless in all of us - can someone describe how this is done for sudo? How do you configure PAM to require alternative passwords, which expire and age, and are decent passwords? And how does one reliably log sudo logs offsite? Micah
Re: shared root account
I agree with this assessment of Andreas' - in fact this is what we use in our organization. Unfortunately we don't have the luxury of fully trusting admins, so I am a little paranoid about giving out full-on sudo to people, but this is mostly a personnel issue having to do with the nature of the industry with which our organization operates. Having said that we do it this way as well, I'll point out one flaw which particularly nags at me. Andreas said, a) allowing convenience by allowing the user to effectively choose their own root passwd. which roughly equivicates to the difference between having one root password that can be cracked to get to the system, to having N+1 root passwords that can be cracked to get at the system (where N=number of admins with sudo access). At this point it is a toss up - is the convenience of not having to pass around the root password to all the admins worth the additional cracks? Do you trust each admin to be secure with both their password choices as well as the rest of their actions? Micah On Sun, 08 Jul 2001, Andres Salomon wrote: This is completely off-topic at this point, but there are a few uses of sudo. The original poster trusts his admins, and wants to give them all root privs without the hassle of having them all use one account. Sudo is not enforcing anything in this case, it is merely a) allowing convenience by allowing the user to effectively choose their own root passwd. b) allowing a form of audit trail; true, it's easy enough to bypass, but someone trusted wouldn't go out of their way to bypass it. It's good for when (for example) samba suddenly stops working, instead of checking /root/.bash_history for editor /etc/smb.conf, running `last` to see when root has logged in since it broke, etc etc, you simply check your logs for the last time someone sudo'd editor smb.conf. Make it policy for admins to not use `sudo bash`, or anything similar. What you people are talking about is adding privs to an untrusted account. The (ridiculous) example given, of allowing a user to run /bin/cat, is similar doing a `chown root:untrusted user /bin/cat; chmod 4770 /bin/cat`. It's dangerous. What a _sane_ admin would do, if the user needed to view a file, is provide the argument to cat that was required. username ALL=(root) /bin/cat /etc/[a-zA-Z]. Or specify the exact filename. If it's an untrusted user, they should be given as little leeway as possible. Allowing them to cat any file on the system is just stupid. On Sat, Jul 07, 2001 at 02:10:09AM +0100, Eric E Moore wrote: Resent-Date: Fri, 06 Jul 2001 21:11:34 -0400 Ethan == Ethan Benson [EMAIL PROTECTED] writes: Ethan or even seemingly innocuous things like less or even cat. Less is a problem, yes, as is anything else with a shell escape. Ethan sudo less anything !/bin/sh whoami r00t! Ethan echo me ALL=ALL s sudo 'cat s /etc/sudoers' doesn't work. the is a shell redirection, but sudo doesn't evaluate in a shell. $ echo me ALL=ALL s $ cat s me ALL=ALL $ sudo 'cat s foo' sudo: cat s foo: command not found $ sudo cat s \ foo me ALL=ALL cat: : No such file or directory cat: foo: No such file or directory I would be very shocked if you could compromise a system with a sudoers entry of: me hostname = (root) /bin/cat Ethan sudo is a very large cannon which is difficult to keep aimed Ethan away from the foot... That it is. But then, the root password is basically a very large cannon built into your shoe. -Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ... being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed. - Unix for Dummies, 2nd Edition -- found in the .sig of Rob Riggs, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
psuedonymity and apache
I am interested in finding a way to make apache be pseudo-anonymous in its logging. Your actions would be traced to your pseudonym, but NEVER to your actual identity. I've got some php scripts that currently act on IP addresses to see if you've already done something so you don't do it again, but I really don't like logging people's IP addresses when possible. However, there are a number of reasons why a webserver would not want true anonyminity (in otherwords I dont just want to change LogFormat to remove IPs completely), such as dealing with abuse, log analysis (analog uses IP addresses to make a best guess of unique visitors based on IP), etc. I thought of saving IPs by doing a one-way hash on them (like a md5 sum?) which would preserve the uniqueness of the IP but also preserve the anonyminity - however in hashing IPs the search space is too small, with a big iron you could run through the possible hashes in about an hour, so it could be undone without much effort. IPv6 would change this of course. Is there an apache mod to do this? Has someone done this with a mod_perl thing? Does anyone have any good ideas on how to do this? I am looking for specifics, not something like Write a perl script, that'll do it. Thanks! Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
psuedonymity and apache
I am interested in finding a way to make apache be pseudo-anonymous in its logging. Your actions would be traced to your pseudonym, but NEVER to your actual identity. I've got some php scripts that currently act on IP addresses to see if you've already done something so you don't do it again, but I really don't like logging people's IP addresses when possible. However, there are a number of reasons why a webserver would not want true anonyminity (in otherwords I dont just want to change LogFormat to remove IPs completely), such as dealing with abuse, log analysis (analog uses IP addresses to make a best guess of unique visitors based on IP), etc. I thought of saving IPs by doing a one-way hash on them (like a md5 sum?) which would preserve the uniqueness of the IP but also preserve the anonyminity - however in hashing IPs the search space is too small, with a big iron you could run through the possible hashes in about an hour, so it could be undone without much effort. IPv6 would change this of course. Is there an apache mod to do this? Has someone done this with a mod_perl thing? Does anyone have any good ideas on how to do this? I am looking for specifics, not something like Write a perl script, that'll do it. Thanks! Micah
Re: Followup: Syslog
One additional tweak which falls into line with the security setups, that I
think is a good idea is to made the log files in /var/log to be chattr +a
(append only) so logfiles cannot be modified or removed altogether to cover
up tracks. This isn't the the biggest security trick because all it does is
make it if you don't know about chattr then you can't install a trojan. If
you've got root then removing the immutability flags is trivial, but only if
you know how to, or even know they exist. But it has kept the lower-level
admins at a site I work at from modifying the logfiles, which is against
policy.
In order to do this properly you need to modify the sysklogd scripts to set
and unset them during rotation (/etc/cron.daily/sysklogd and
/etc/cron.weekly/sysklogd) - on a side note, why are system logs rotated
through sysklogd and other logs like btmp are rotated with logrotate? Why
aren't these all done via logrotate? - the way I modified these files was as
follows:
(this is the snippit from /etc/cron.weekly/sysklogd that is different)
cd /var/log
for LOG in syslogd-listfiles --weekly
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-4]
chattr -i $LOG.[0-4].gz
savelog -g adm -m 640 -u root -c 4 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-4]
chattr +i $LOG.[0-4].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
done
(Here is the snippit from /etc/cron.daily/sysklogd that is different):
cd /var/log
for LOG in syslogd-listfiles
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-7]
chattr -i $LOG.[0-7].gz
savelog -g adm -m 640 -u root -c 7 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-7]
chattr +i $LOG.[0-7].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
Kenneth Vestergaard Schmidt schrieb am Samstag, den 14. April 2001:
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough "wishlist" here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the "Securing Debian Manual"
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if "the people" think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
PGP signature
Re: Followup: Syslog
One additional tweak which falls into line with the security setups, that I
think is a good idea is to made the log files in /var/log to be chattr +a
(append only) so logfiles cannot be modified or removed altogether to cover
up tracks. This isn't the the biggest security trick because all it does is
make it if you don't know about chattr then you can't install a trojan. If
you've got root then removing the immutability flags is trivial, but only if
you know how to, or even know they exist. But it has kept the lower-level
admins at a site I work at from modifying the logfiles, which is against
policy.
In order to do this properly you need to modify the sysklogd scripts to set
and unset them during rotation (/etc/cron.daily/sysklogd and
/etc/cron.weekly/sysklogd) - on a side note, why are system logs rotated
through sysklogd and other logs like btmp are rotated with logrotate? Why
aren't these all done via logrotate? - the way I modified these files was as
follows:
(this is the snippit from /etc/cron.weekly/sysklogd that is different)
cd /var/log
for LOG in syslogd-listfiles --weekly
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-4]
chattr -i $LOG.[0-4].gz
savelog -g adm -m 640 -u root -c 4 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-4]
chattr +i $LOG.[0-4].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
done
(Here is the snippit from /etc/cron.daily/sysklogd that is different):
cd /var/log
for LOG in syslogd-listfiles
do
if [ -f $LOG ]; then
chattr -ia $LOG
chattr -i $LOG.[0-7]
chattr -i $LOG.[0-7].gz
savelog -g adm -m 640 -u root -c 7 $LOG /dev/null
chattr +a $LOG
chattr +i $LOG.[0-7]
chattr +i $LOG.[0-7].gz
fi
done
for LOG in syslogd-listfiles --auth
do
if [ -f $LOG ]; then
chown root.adm $LOG
chmod o-rwx $LOG
chattr +a $LOG
fi
Kenneth Vestergaard Schmidt schrieb am Samstag, den 14. April 2001:
(Sorry for the crosspost, but I want to get as much coverage as possible)
First of, thank you everyone for responding! It's given me some food for
thought, and I also found a lot of errors in what I thought would be best.
Anyway, I've compiled a rough wishlist here, listing what people (including
me) generally request. The reason for this is to get a discussion started, so
we can all have the most efficient (and secure) logging possible. Please
comment (if you wish) on the points noted here, but don't feel restricted to
only those - I'm more than willing to consider other features...
Here it goes:
o One log with everything (like /var/log/syslog)
o Authentication log (/var/log/auth.log)
o Non-important stuff in separate logs (/var/log/service.{info,warn,err}
o Human-readable datetime
o Machine-processible (ie, fixed field widths, like now)
o High-precision date/time (TAI64?)
o Docs + inclusion in the Securing Debian Manual
o /secure/ remote-logging (ie, crypto)
o Fallback log (ie, if something gets missed, it is logged to fx.
/var/log/missed)
o Permission checking (?)
o Running as non-root
o Encrypted logs (Compressed?)
o User-defined facilities (ie, firewall.info, xfree.err)
After reading through the features which people would like to see, it seems
to me that there is really need for something else besides sysklogd. What I
really want to know is, why is syslog-ng and/or msyslog not more widely used?
What do they lack? Compatibility and security are the only points I can see
where they might not qualify as a total replacement.
With that in mind, I've been considering making my own logger. Is this a good
idea? I've considered it a bit, and thought it would be best to start with
the current sysklogd source, and make small, tested changes to be sure that
it's still safe working. What do people think of this?
So, anybody want to jump in and make some comments? Even if you think it's
trivial what you have to say, please do so anyway. If you feel it's not worth
everybody's mailbox, just mail me personally. Think of it as a poll :)
And also, if the people think it's a good idea with a new syslogger, then
there's the all-important question of the project name. Ideas are welcome :)
Yours truly
Kenneth Vestergaard Schmidt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pgp3xZVnBNjkd.pgp
Description: PGP signature
Weird protocol
Noticed a weird entry in my firewall logs, it is listed as protocol 54, but according to /etc/protocols that doens't exist, anyone know what this is? Mar 5 23:12:20 stall kernel: Packet log: input REJECT eth0 PROTO=54 165.230.59.207:65535 x.x.x.x:65535 L=68 S=0x00 I=0 F=0x T=10O=0x0494 (#106) Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Weird protocol
Noticed a weird entry in my firewall logs, it is listed as protocol 54, but according to /etc/protocols that doens't exist, anyone know what this is? Mar 5 23:12:20 stall kernel: Packet log: input REJECT eth0 PROTO=54 165.230.59.207:65535 x.x.x.x:65535 L=68 S=0x00 I=0 F=0x T=10O=0x0494 (#106) Micah
Woody ssh exploit
We are currently running woody on a production machine (yes, I am not that happy about that decision). Woody does not get potato's security updates, and does not get new unstable security fixes in a timely fashion. This leaves woody vulnerable to certain kinds of problems, particularly distressing right now is the ssh security issue that is out there, which woody does not have a fix for. Potato has a fix at http://www.debian.org/security/2001/dsa-027 So how do we fix this on a woody machine? There are a few things that can be done, none of them very great. There is the possibility of putting the potato package on our machine, but are there are dependancy issues or problems downgrading a package from woody to potato? What about when a fix does finally come available for woody, will it be an issue to bring the potato package up to that woody upgrade? There is the possibility of enabling protocol2 only on our ssh installation, which would make us safe, but is only an interim fix until an update comes available for woody, this an issue for people who cannot connect via protocol 2, and an annoyance/education effort for those who connect via protocol 1. All of these aren't great. Unless I am wrong, currently there is no known exploit for this hole, but that isn't that much of a reassurance either. Thanks, Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Woody ssh exploit
We are currently running woody on a production machine (yes, I am not that happy about that decision). Woody does not get potato's security updates, and does not get new unstable security fixes in a timely fashion. This leaves woody vulnerable to certain kinds of problems, particularly distressing right now is the ssh security issue that is out there, which woody does not have a fix for. Potato has a fix at http://www.debian.org/security/2001/dsa-027 So how do we fix this on a woody machine? There are a few things that can be done, none of them very great. There is the possibility of putting the potato package on our machine, but are there are dependancy issues or problems downgrading a package from woody to potato? What about when a fix does finally come available for woody, will it be an issue to bring the potato package up to that woody upgrade? There is the possibility of enabling protocol2 only on our ssh installation, which would make us safe, but is only an interim fix until an update comes available for woody, this an issue for people who cannot connect via protocol 2, and an annoyance/education effort for those who connect via protocol 1. All of these aren't great. Unless I am wrong, currently there is no known exploit for this hole, but that isn't that much of a reassurance either. Thanks, Micah
Re: Strange firewall logs
Ah, looking at my firewall I've got: -A output -s 127.0.0.1/255.0.0.0 -d 127.0.0.1/255.0.0.0 -p 17 -j ACCEPT -A output -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j REJECT -l -A output -s 0.0.0.0/0.0.0.0 -d 127.0.0.0/255.0.0.0 -j REJECT -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l So from what you are saying I should add: -A output -s 127.0.0.1/255.0.0.0 0 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 3 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 4 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 8 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 11 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 12 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT ? Should these be allowable from 127.0.0.1 to anywhere? And would the ICMP port orginate on the 127.0.0.1 end or the destination end? Micah On Sun, 11 Feb 2001, Simon Murcott wrote: Tim Bishopric wrote: This log shows that Ipchains is rejecting outbound loopback (lo) traffic with a source IP of 127.0.0.1 and a destination of 127.0.0.1. Protocol 1 is ICMP (see /etc/services) and I think type 3 reports "destination unreachable." If you block ICMP, you will have problems with DNS, timeouts, etc. More info: http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html#2 It is definitely not wise to block ICMP unreachables, source-quench, parameter-problem and time-exceeded. But it is wise to block ICMP redirect, timestamp-(req|reply), info-(req|reply) and address-(req|reply). The only exception is that if you can trust a router then it MAY be ok to accept redirects from it. I leave pings up to your descretion :p I usually recommend blocking all ICMP except for: 0 echo reply (ping reply) 3 destination unreachable 4 source quench 8 echo request (ping) 11 time exceeded 12 parameter problem This stuff is all diagnostics, the rest has questionable use (even on internal networks). Regards Simon Murcott e. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Strange firewall logs
I am getting a lot of entries in my logs with the following entries from ipchains, I can't quite figure out what port 3 is supposed to be. After searching for some time I seem to have found a solution on a site whose explanation is only in Danish, which I am very inefficient in: Feb 10 15:11:39 stallman kernel: Packet log: output REJECT lo PROTO=1 +127.0.0.1:3 127.0.0.1:3 L=92 S=0xC0 I=1350 F=0x T=255 (#64) Feb 10 15:20:53 stallman kernel: Packet log: output REJECT lo PROTO=1 +127.0.0.1:3 127.0.0.1:3 L=92 S=0xC0 I=3190 F=0x T=255 (#64) Feb 10 15:30:59 stallman kernel: Packet log: output REJECT lo PROTO=1 +127.0.0.1:3 127.0.0.1:3 L=92 S=0xC0 I=4545 F=0x T=255 (#64) Feb 10 15:40:48 stallman kernel: Packet log: output REJECT lo PROTO=1 +127.0.0.1:3 127.0.0.1:3 L=92 S=0xC0 I=5884 F=0x T=255 (#64) Does anyone know what these are? Thanks! Micah
Re: Strange firewall logs
Ah, looking at my firewall I've got: -A output -s 127.0.0.1/255.0.0.0 -d 127.0.0.1/255.0.0.0 -p 17 -j ACCEPT -A output -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j REJECT -l -A output -s 0.0.0.0/0.0.0.0 -d 127.0.0.0/255.0.0.0 -j REJECT -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l -A input -s 127.0.0.0/255.0.0.0 -d 0.0.0.0/0.0.0.0 -j DENY -l So from what you are saying I should add: -A output -s 127.0.0.1/255.0.0.0 0 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 3 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 4 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 8 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 11 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT -A output -s 127.0.0.1/255.0.0.0 12 -d 0.0.0.0/0.0.0.0 -p 1 -j ACCEPT ? Should these be allowable from 127.0.0.1 to anywhere? And would the ICMP port orginate on the 127.0.0.1 end or the destination end? Micah On Sun, 11 Feb 2001, Simon Murcott wrote: Tim Bishopric wrote: This log shows that Ipchains is rejecting outbound loopback (lo) traffic with a source IP of 127.0.0.1 and a destination of 127.0.0.1. Protocol 1 is ICMP (see /etc/services) and I think type 3 reports destination unreachable. If you block ICMP, you will have problems with DNS, timeouts, etc. More info: http://www.linuxsecurity.com/resource_files/firewalls/firewall-seen.html#2 It is definitely not wise to block ICMP unreachables, source-quench, parameter-problem and time-exceeded. But it is wise to block ICMP redirect, timestamp-(req|reply), info-(req|reply) and address-(req|reply). The only exception is that if you can trust a router then it MAY be ok to accept redirects from it. I leave pings up to your descretion :p I usually recommend blocking all ICMP except for: 0 echo reply (ping reply) 3 destination unreachable 4 source quench 8 echo request (ping) 11 time exceeded 12 parameter problem This stuff is all diagnostics, the rest has questionable use (even on internal networks). Regards Simon Murcott e. [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Speaking of broadcasts, is this a security threat?
Well - I was more thinking that whatever service is sending these regularly scheduled broadcasts ought to be choked. I don't have any reason for kerberos to be on and it sort of disturbs me that I can't find this service in either my /etc/services file or even inetd.conf. Micah On Wed, Aug 09, 2000 at 09:15:33PM +0200, Ron Rademaker wrote: Well, you are already telling it to 'shut up' by denying it. If you don't want the denies to show up in your logs, you'll just have to put off the logging option in ipchains. Ron Rademaker On Tue, 8 Aug 2000, Micah Anderson wrote: Every few minutes I see the following show up in my log: Aug 8 00:03:17 riseup kernel: Packet log: input DENY eth0 PROTO=17 +10.0.0.1:1999 255.255.255.255:1999 L=94 S=0x00 I=638 F=0x4000 T=1 (#4) Aug 8 00:49:40 riseup kernel: Packet log: input DENY eth0 PROTO=17 +10.0.0.1:1999 255.255.255.255:1999 L=94 S=0x00 I=639 F=0x4000 T=1 (#4) Aug 8 00:03:17 riseup kernel: Packet log: input DENY eth0 PROTO=17 +10.0.0.1:1999 255.255.255.255:1999 L=94 S=0x00 I=638 F=0x4000 T=1 (#4) Aug 8 00:49:40 riseup kernel: Packet log: input DENY eth0 PROTO=17 +10.0.0.1:1999 255.255.255.255:1999 L=94 S=0x00 I=639 F=0x4000 T=1 (#4) Now if I interpret this correctly this means that my internal network interface is broadcasting protocol 1999 (which is like a kerberos thing? I dont know, I don't have kerberos installed, enabled or anything on my system) - but it seems to be blasting it out and I am trying to deny it. Is this actually something on my end that I need to tell to shutup, or is someone doing this to me? Either one, how can I make it stop?? Thanks! Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
