Re: How do you guys handle PNG/JPG binary files with potential payloads for all the image viewers?
On Mon, Jun 20, 2022 at 09:25:38AM -0700, Noah Meyerhans wrote: > https://security-tracker.debian.org/tracker/source-package/imagemagick > > If you're processing data (images, videos, audio files, etc) from > unknown sources, it's a really good idea to use sandboxing of some kind, > ensure that sandboxes are never reused, and to ensure that only the most > minimal state possible (e.g. the output of the processing job) is > preserved after execution. The sandbox can use things like seccomp and > apparmor to enforce containment. Linux namespaces are useful as well: A > private network namespace that doesn't have access to the outside world, > a private mount namespace that has a unique root file system (ideally > read-only), etc. > > Containers, as implemented by podman, docker, and systemd-container can > help here by providing convenient interfaces to these process isolation > tools. Sorry, hit send before I mean to. The above is all about protecting against new, unknown issues for which the mitigation isn't known. For protection against known issues, of course, you should simply make sure you're running up-to-date versions of all your software. noah
Re: How do you guys handle PNG/JPG binary files with potential payloads for all the image viewers?
On Mon, Jun 20, 2022 at 06:10:45PM +0200, Sebastian Rose wrote: > >> how do you guys test all of the potential PNG/JPG potential malware > >> payloads > > What's your use-case? As I'm not aware of an vector for GNU/Linux in > normal everyday use¹, I guess you host files for Windows clients? https://security-tracker.debian.org/tracker/source-package/imagemagick If you're processing data (images, videos, audio files, etc) from unknown sources, it's a really good idea to use sandboxing of some kind, ensure that sandboxes are never reused, and to ensure that only the most minimal state possible (e.g. the output of the processing job) is preserved after execution. The sandbox can use things like seccomp and apparmor to enforce containment. Linux namespaces are useful as well: A private network namespace that doesn't have access to the outside world, a private mount namespace that has a unique root file system (ideally read-only), etc. Containers, as implemented by podman, docker, and systemd-container can help here by providing convenient interfaces to these process isolation tools. noah
Re: Fwd: Re: Fwd: What is the best free HIDS for Debian
Can we please take this tinfoil hat lunacy somewhere else? There are plenty of conspiracy theory forums out there. I'm sure you've got your favorite, but this isn't one. On Fri, May 13, 2022 at 08:15:52PM +0200, Elmar Stellnberger wrote: > I mean Michael Lazin didn´t say anything bad, on the contrary he has given > us some valuable information. I just wanted people to know here that secret > services apparently have their people posting on this list, likely not > always disinterestedly. I have double checked with Sylvain - her mail had in > deed been written to be between her and me only although it had been cited > by this person. > > Elmar > > Am 13.05.22 um 20:01 schrieb estel...@elstel.org: > > Michael Lazin had published a private email between me an Sylvain > > Sécherre. It means he is an NSA guy, since he had access to a wiretapped > > conversation. > > > > https://lists.debian.org/debian-security/2022/05/msg00018.html > > > > Originalnachricht > > Betreff: Re: Fwd: What is the best free HIDS for Debian > > Datum: 12.05.2022 12:53 > > Von: Sylvain Sécherre > > An: Elmar Stellnberger > > > > > > > > Dear Elmar, > > > > Don't worry about this, feel free to cite me if you want, even if it was > > a private mail. > > > > However, I'd prefer posting on usenet because it's a sharing attitude! > > So, if you don't mind, let's continue this topic on > > linux.debian.security. > > > > Best regards, > > > > Sylvain > > > > ... >
Re: GPG verification of apt packages
On Thu, Jan 28, 2021 at 10:08:32AM -0800, Ramin Doe wrote: > The signed metadata includes cryptographic checksums of the package > contents. Thus, package contents can't be modified in storage on the > mirror or in transit to your system without invalidating the checksum, > and the checksums can't be updated in the repository metadata without > invalidating the signature. > >This all sounds pretty promising! Thank you, Noah! Do you happen to know >how to access this metadata? I'd love to be able to look at it and >understand it better. See the signed InRelease files in /var/lib/apt/lists >Again, I'd love to see one of these release files, so I could see: >a) what data, exactly, is being checksummed >b) what sort of hash algorithm is involved >In my digging around so far, I found that the .deb file contains a >control.tar.xz file, which has some md5 checksum information, but it has >very patchy coverage of the files in the package. I hope that's just a >holdover from a deprecated mechanism, and is not being used nowadays. The MD5 sums are use by the debsums program. Because md5 is weak and because there are plenty of ways to bypass file-level checksum validation in general, these are more useful at identifying corruption or valid local modifications rather than system compromise. You should read https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html It's a little dated, as it still mentions the use of md5 in the Release files when we use sha256 these days, but it's good for a higher level overview. noah signature.asc Description: PGP signature
Re: GPG verification of apt packages
On Wed, Jan 27, 2021 at 10:23:44AM -0800, Ramin Doe wrote: >This lead me to search for more answers online, where I have found an >article that suggests that package metadata is verified, but that package >contents are not. > > ([1]https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/) The signed metadata includes cryptographic checksums of the package contents. Thus, package contents can't be modified in storage on the mirror or in transit to your system without invalidating the checksum, and the checksums can't be updated in the repository metadata without invalidating the signature. >I do know that if I use "apt download" to download a .deb file, break it >apart (using ar and tar), make a change, and put it back together, I can >the use "apt install ./X.deb" to install it, even though I haven't updated >any security metadata in the .deb file. Removing "no-debsig" in dpkg.cfg >doesn't affect the outcome. That's correct; the validation happens during retrieval. Once the package is on your computer, you are free to tamper with it however you want. >And finally, it seems that even wikipedia says that package signatures >aren't being checked on most systems >([3]https://en.wikipedia.org/wiki/Deb_%28file_format%29#Signed_packages). That's correct; package validation is done as described above. You left out the part of the wikipedia article that states that "packages are verified by signing the repository metadata (i.e. Release files). The metadata files in turn include checksums for the repository files as a means to verify authenticity of the files." noah signature.asc Description: PGP signature
Re: Thunderbird in Debian testing
On Wed, Oct 21, 2020 at 09:22:11PM +0300, Pavlos Ponos wrote: >Thunderbird 1:78.3.1-2 accepted in unstable at 30/09/2020, 21 days passed >since then, so i think it would be enough time to consider it ready for >testing. Normally it would be, but issues (release-critical bugs, test regressions, etc) can arise that block its transition. Issues with a package's dependencies can also impact its transition. In this case, manual intervention was required to get it to transition in reasonable timeframe. noah
Re: Thunderbird in Debian testing
On Wed, Oct 21, 2020 at 07:03:35PM +0300, Pavlos Ponos wrote: >Apologies if this should be directed to another list, but I've already >tried in 'debian-testing' with no luck, see [1]here. >In Debian's package tracker I see that Thunderbird in stable through the >security updates is in 1:78.3.1-2~deb10u2 while in testing is in >1:68.12.0-1. How is it possible for the old-stable to have the same >version with stable, but not testing? Stable updates are handled by the security team and are made as necessary. Testing doesn't work that way. Changes to testing arrive only after spending some time in unstable. See https://www.debian.org/doc/manuals/debian-faq/choosing.en.html#s3.1.7 and https://www.debian.org/security/faq#testing >[2]https://tracker.debian.org/pkg/thunderbird Tracker indicates that thuderbird will propagate to testing in the next couple of days based on a manual hint by the release team: Migration status for thunderbird (1:68.12.0-1 to 1:78.3.3-1): Will attempt migration due to a hint (Any information below is purely informational) >Security repository is enabled in my /etc/apt/sources.list file >deb [3]http://security.debian.org/debian-security/ testing-security main That repository is empty and is typically not used at all except during a freeze when automatic propagation from unstable is disabled. noah
Re: package for security advice
On Sat, Mar 07, 2020 at 08:22:59PM +1100, Russell Coker wrote: > For subsystems that are complex and security critical (like Apache and Samba > for example) you could have other packages providing check scripts that look > for common configuration choices that might reduce security. Such scripts > would be designed to give false positives rather than false negatives. The > idea being that if you do something potentially risky then you should be > aware > of it and so should whoever takes over your job in a few years time. Then at > relevant times (EG after an upgrade to a new release of Debian) decisions > about security can be reviewed. I worry that package-specific guidelines will be hard to maintain with uniform quality over time. Do general tools for evaluating the security posture of an Apache or nginx installation exist today? How useful are they? If they exist and are useful, can we package them? If they don't exist, why not? My guess is that high quality tools don't exist today, in large part because web server security is so application dependent. A tool to provide a baseline evaluation of general system security seems worthwhile. Especially if we're diligent about updating it as new hardware security flaws are found and mitigated, etc. noah
Re: package for security advice
On Sat, Mar 07, 2020 at 11:46:54AM -0600, Jonathan Hutchins wrote: > The only way to achieve real security is through knowledge. Pressing a > shiny automated button is just going to implement what somebody else thinks > is good for the system they assume you're running. Find the security > websites, podcasts, newsletters, books. Learn what you really need to do > for your actual case, not what somebody else thinks you should do. Learn > what is superstitious paranoia that will never even come close to a private > personal system. By your logic, we shouldn't bother taking any steps to help our users secure their systems. Everything should be on them. This may come as a surprise to you, but many computer users (I'll stop short of saying anything about "the vast majority"), have no interest whatsoever in "security websites, podcasts, newsletters, books". But guess what, they're still using computers, and they're not going to stop. We can either help them do so a little more safely, or we can watch them fail. One of these choices is aligned with our social contract. > If you're going to run a public web server, mail server, or whatever, one > run of a script is not going to keep you secure. You need to know what the > actual attack vectors can be, and need to be prepared for a threat that > nobody's thought of yet. Why? *Somebody* certainly needs to think about these things, but the notion that *everybody* needs to do so to the deepest possible level ignores the reality of human nature. It is our responsibility as a Linux distribution to make difficult OS management tasks easier, and that includes taking reasonable steps to configure a system for use on today's internet. > Microsoft tells you all you have to do is click the little check box that > turns on the security they've built and you're all safe. We're not talking about Microsoft. noah
Re: haveibeenpwned -> sub...@bugs.debian.org and others
On Sat, Jan 06, 2018 at 05:10:10PM +0100, Davide Prina wrote: > https://haveibeenpwned.com/ > > that inform you if your credential have been compromised in data brench > (only for public compromised data). > > I have try it with sub...@bugs.debian.org and this account result > compromised!! for: Email addresses, Passwords, Device usage tracking data, > Names, Physical addresses Thanks for your concern. However, I suspect it's misplaced in this case. haveibeenpwned.com works largely by indexing and scanning public text sharing sites like pastebin.com. Given the nature of sub...@bugs.debian.org, it's fully expected to show up in lots of content on such sites. > Have this address a password? > Can this be a security issue? (If this is not know and the password was not > changed) sub...@bugs.debian.org is not an email account with a password, so there's no risk of password compromise. > I have see that also other Debian mail result compromised: > secur...@debian.org > debian-security@lists.debian.org > requ...@bugs.debian.org > listmas...@lists.debian.org > debian-de...@lists.debian.org > debian-proj...@lists.debian.org > debian-security-annou...@lists.debian.org > debian-i...@lists.debian.org > debian-ital...@lists.debian.org > debian-l10n-ital...@lists.debian.org What I said about sub...@bugs.debian.org applies equally to these addresses as well. noah signature.asc Description: PGP signature
Re: gnupg upload for CVE-2017-7526
On Wed, Aug 30, 2017 at 08:49:44AM +0200, Guido Günther wrote: > Hi gnupg maintainers, security team, > attached debdiff addresses the above CVE for jessie. O.k. to upload to > security-master? debian-security@lists.debian.org is the public discussion list and isn't necessarily monitored by the security team. You wanted t...@security.debian.org as per https://www.debian.org/security/faq#contact noah signature.asc Description: PGP signature
Re: [SECURITY] [DSA 3501-1] perl security update
On Tue, Mar 01, 2016 at 08:35:43PM +0100, Zack Piper wrote: > > "someone take my email off the list or I will report it as harassment." > > Oh wow I forgot about this. They've tried unsubscribing in the past > from other lists just to refuse to follow instructions' I imagine > they're a troll. It doesn't help that *everybody* here has given incorrect instructions so far. He replied to a post to debian-security-annou...@lists.debian.org yet everybody who replied to him how to unsubscribe from debian-security@lists.debian.org. Amazing how he's still on the list, isn't it? noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 3481-1] glibc security update
On Tue, Feb 16, 2016 at 04:32:00PM +0100, Peter Ludikovsky wrote: > A question to those more knowledgeable: we're using our own DNS > servers for all lookups, and those do recursive lookup for any > external addresses. Am I right to assume that Bind9 uses it's own > implementation for DNS lookups? Or are those now basically ticking > time bombs? Bind does not use getaddrinfo() when performing DNS lookups on behalf of clients. However, it may use it when resolving hostnames listed in configfiles, e.g. in the masters list for a slave zone. If at all possible, I would update libc and restart named, which should be sufficient to protect that particular service from impact. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 3438-1] xscreensaver security update
On Mon, Jan 11, 2016 at 11:14:52AM -0500, Cindy-Sue Causey wrote: > Just thinking out loud... that maybe the Announce list settings might > need a quick once-over review depending on admin's intentions for it. The ability to send mail to the debian-security-announce list is restricted, and the settings work as intended. Note that Debian security announcements include a Reply-To header redirecting replies to the debian-security@lists.debian.org discussion list, so it's possible to send a reply and think that it did go through, when in fact it went to a different mailing list. In fact, that's exactly what's happening here. This thread is taking place on debian-security@lists.debian.org, even though it was triggered by a reply to a security announcement on debian-security-announce. noah signature.asc Description: Digital signature
Re: Debian Mentoring for Security Team
On Wed, Sep 09, 2015 at 01:24:05PM -0400, Justin R. Andrusk wrote: > Was just wondering if there was any mentoring opportunities available on > the Debian Security team. Per https://www.debian.org/security/faq#contact you should be contacting t...@security.debian.org to reach the security team. This mailing list is for public discussion of Debian security concerns and isn't necessarily monitored by the security team. noah signature.asc Description: Digital signature
Re: Archived Debian releases without security site: lists.debian.org
On Sun, May 03, 2015 at 10:06:20PM +0530, bkpsusmitaa wrote: I have added the lines. The issue is regarding non-availability of security keys. Yes, it is about an old laptop that ran superbly in lenny, but somewhat slower in squeeze, The keys are available in the debian-archive-keyring package. The one referenced by lenny's package metadata is debian-archive-keyring_2010.08.28~lenny1_all.deb and can be retrieved from http://archive.debian.org/debian/pool/main/d/debian-archive-keyring/ Specifically, the lenny release file is signed with key 473041FA. You can also retrieve this key from a keyserver network with commands like: gpg --recv-keys 473041FA gpg --export -a 473041FA | sudo apt-key add - signature.asc Description: Digital signature
Re: streql - Constant-time string comparison
On Sat, Nov 01, 2014 at 04:21:53PM +, Jack wrote: This mailing list is for security announcements. All Debian users are encouraged to subscribe, so that they know about the latest threats and updates. Incorrect; you're thinking of debian-security-announce, which is moderated and only used for announcements. debian-security is a discussion list. It is not reasonable to use this list as a forum for discussing a Python string-comparison routine. Can you please take your discussion somewhere else? Given the long history of security ramifications of string handling on Unix (and even non-Unix) systems, I don't think you can make that claim without qualification. Though I'll agree that the current discussion may be somewhat off-topic. noah signature.asc Description: Digital signature
Re: concrete steps for improving apt downloading security and privacy
On Sun, Jul 13, 2014 at 08:35:56AM +0900, Joel Rees wrote: MD5 has been broken for a small number of applications. Its status is questionable for the rest, but if we want to help break it completely, let's get all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images. The point that you miss is that a chosen plaintext attack is not dependent on the secret key in use. It's an attack against the algorithm itself. If we sign publically available data (be it Debian packages, CD images, or this email) with a given key, we really aren't giving our adversaries anything that they can't create for themselves. Keys are cheap to generate. If an adversary wants to perform chosen plaintext analysis, they can do so today with their own keys and with all the common public datasets they want. Getting all the distros that insist on still using MD5 to use it, not just for signing, but for encrypting their distribution images won't change anything. (Not to mention that it shows a fundamental misunderstanding of what a digest algorithm like md5 actually is.) noah signature.asc Description: Digital signature
Re: finding a process that bind a spcific port
On Jan 22, 2014 9:11 AM, Nico Angenon n...@creaweb.fr wrote: Here is the ps aufx result... (a bit long) (Please excuse any wonky formatting or glaring oversights, I'm on a mobile device.) You appear to be running an nfs server on this host. Try stopping the nfs-kernel-server service and see if anything changes. SNIP root 11015 0.0 0.0 0 0 ? S 2013 0:00 \_ [rpciod/0] root 11017 0.0 0.0 0 0 ? S 2013 0:00 \_ [rpciod/1] root 11018 0.0 0.0 0 0 ? S 2013 0:00 \_ [rpciod/2] root 11019 0.0 0.0 0 0 ? S 2013 0:00 \_ [rpciod/3] ... root 11024 0.0 0.0 0 0 ? S 2013 0:00 \_ [nfsiod] ... root 29114 0.0 0.0 18736 812 ? Ss 13:16 0:00 /sbin/rpcbind -w
Re: NSA software in Debian
On Sat, Jan 18, 2014 at 08:30:49PM +0100, Marco Saller wrote: i am not sure if this question has been asked or answered yet, please do not mind if i would ask it again. Is it possible that the NSA or other services included investigative software in some Debian packages? It is absolutely possible. It's even possible that you yourself have added such software to Debian! Can you prove that you haven't? That line of thinking leads to madness. The only rational conclusion, once you start down that path, is to turn off your computers and move to a remote cabin in the wilderness. It will never be possible to prove that there is no malicious software in Debian or in any other OS. Beyond that, it will never be possible to prove that there is no malicious *hardware* running executing your OS. We can and do take care to ensure that all changes to Debian are made by people authorized to make those changes. (Package uploads must be signed by a Debian developer.) We can and do take care to ensure that that the packages you download have not been modified in transmission (signing of Release files, checksums on Packages files and on packages themselves.) Etc. If deficiencies are found in our mechanisms or policies, then we take steps to improve them. If violations are found, then we take steps to audit for impact and resolve any potentially malicious actions that we identify. We take great care to minimize the likelihood of any sort of backdoor or malicious code in Debian, but none of this can provide 100% proof that such a thing doesn't exist. Anybody that claims that they can prove otherwise, for Debian or any other OS, is either lying or ignorant. noah signature.asc Description: Digital signature
Re: NULL Scan issues or something else?
On Tue, Feb 05, 2013 at 10:45:39PM +, Jérémie Marguerie wrote: You'll be scanned, many times a day, you'll also be bruteforced and however not normal, this is just noise. See also http://en.wikipedia.org/wiki/Internet_background_radiation signature.asc Description: Digital signature
Re: idea: switch default MTA from exim4 to postfix (wheezy+1)
On Thu, Nov 01, 2012 at 10:48:46PM +0900, Hideki Yamane wrote: So I suggest switch from Exim to Postfix for default MTA. This has been discussed in depth fairly recently on debian-devel. http://lists.debian.org/debian-devel/2012/04/msg00719.html The short answer, from my recollection of that thread, was that if we ever do switch from exim, it'll be to a dummy mta like ssmtp, nullmailer, or similar. Not to another full-featured mta like postfix. noah signature.asc Description: Digital signature
Re: need help with openssh attack
On Thu, Dec 29, 2011 at 04:39:24PM +0100, Kees de Jong wrote: I guess I already pointed out everything. I added the updating part to it. * Use private not public keys with strong passwords This doesn't make any sense at all. You need both private and public keys for key-based authentication, and it's very important that you recognize the difference between the two. Also, one of the real problems with ssh key authentication is that there's no way to enforce a strong password policy on the private keys. Plenty of times I've seen an otherwise secure host compromised when a user did something silly like drop their passwordless private key in their public_html folder. noah signature.asc Description: Digital signature
Re: need help with openssh attack
On Thu, Dec 29, 2011 at 11:30:27PM +0400, Taz wrote: Anybody want's to check it out? I can provide ssh access, if u will give me ssh key. From the sound of things, we're not going to find much. It's clear that the attackers have already cleaned up their tracks by editing auth.log, etc. The detailed forensics needed here would likely take a fair bit of time. Also, because we'd be working on a compromised host, we likely couldn't even trust our own tools to give us accurate information. File-system level forensics would be best performed on a block-level image of the disk itself (e.g. made using something like dd). One recommendation I've got for future deployments, if you can allocate the resources for it, is to have a dedicated syslog host. This host should not run any services other than syslogd, including ssh. Any access would need to be via the console. You should be careful to give it a unique root password, and probably don't even bother to create any non-root accounts on it. Configure the rest of your hosts to send their logs to this host. Having a copy of things like auth.log whose integrity can be trusted would be most helpful here. noah signature.asc Description: Digital signature
Re: Command 'su' is not working in virtual console
On Fri, Dec 16, 2011 at 09:34:40PM +0100, Marko Randjelovic wrote: snip ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff98fbd270) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff98fbd3e0) = -1 ENOTTY (Inappropriate ioctl for device) snip Those are the key bits. What is $TTY set to? Is /dev/pts mounted? Does the file referenced by $TTY exist? Can you post the output of ls -l $TTY ? signature.asc Description: Digital signature
Re: Debian LTS?
On Wed, Oct 05, 2011 at 09:15:18PM +0100, Bart Swedrowski wrote: I have been forced to use switch from Debian to RedHat and clones in my last job specifically because usual life time of a server was 3.5 - 4 years. Same here. In my exerience, large sites typically use a 3-5 year lifetime for hardware, and the OS is never upgraded once a host goes into production. If you've got thousands of hosts, all of which are doing just fine in terms of software functionality and are in a static, generally unchanging production configuration, there's very little benefit to performing an OS upgrade. On the other hand, many of these large environments don't see a lot of value in Debian's major contributions. The Social Contract is not typically not a very important consideration when large enterprises choose a software platform. The OS environments are pretty strictly defined and generally don't change much, so they don't see a lot of value in Debian's package management tools. Canonical and Redhat both need to earn money, and it's worth a lot of money to big companies to have an LTS software platform. Debian doesn't need money, and (afaict) there's not a particularly large community of volunteers interested in the difficult task of maintaining an LTS platform. It's a generally thankless task that involves working on ancient versions of packages, often coming up with new fixes to old bugs so you can maintain existing interfaces, when the obvious fix would involve changing the behavior of a program or a library's API or some such. noah signature.asc Description: Digital signature
Re: Debian LTS?
On Thu, Oct 06, 2011 at 12:33:39AM +0200, Poison Bit wrote: In my experience: if a company does not perform operative system upgrades, the company does not have more than 5 years and does not understand how open source, and in special linux kernel, works. I'm certain I can name several large companies that have been around for more than 5 years and whose services you rely on that do not perform os upgrades on hardware once it enters production. You can migrate data between service versions or environments, have rollbacks, backups and etc. Across a fleet of 15000 hosts? With no downtime? Without impacting the schedule of whatever software you actually run on these hosts? The monolitic one server, all services, never upgrade maybe just an architecture issue, totally outside of the Debian issues. That's not what I'm describing at all. Those places can and should upgrade. I'm talking 1 service to 1 host, multiplied by thousands. These are the companies that want LTS support. noah signature.asc Description: Digital signature
Re: Debian LTS?
On Thu, Oct 06, 2011 at 12:15:45AM +0200, Sythos wrote: And that's 2 years less for LTS ... especially in bigger Setup's LTS-Support is mandatory so there (because there is no Debian LTS's) Debian cannot be used due to the lack of Support. Instead - Redhat or Ubuntu or any other distribution with LTS-Support is used there. 3 years of direct support of stable and so 1-2 years of oldstable support mean a amount of 4-5 years, please define again what you mean for LTS... Debian's goal is to have an 18 month release cycle. stable becomes oldstable when the next version is released, and oldstable is supported for 1 year. That's 28 months. Where do you get the idea of 3 years of direct support as stable? Those days are (hopefully) long gone. noah signature.asc Description: Digital signature
Re: Debian LTS?
On Wed, Oct 05, 2011 at 03:20:08PM -0700, Noah Meyerhans wrote: Debian's goal is to have an 18 month release cycle. stable becomes oldstable when the next version is released, and oldstable is supported for 1 year. That's 28 months. Where do you get the idea of 3 years of direct support as stable? Those days are (hopefully) long gone. Err, that's 30 months, sorry. But the point stands. :) noah signature.asc Description: Digital signature
Re: Debian LTS?
On Thu, Oct 06, 2011 at 12:47:09AM +0200, Poison Bit wrote: You can migrate data between service versions or environments, have rollbacks, backups and etc. Across a fleet of 15000 hosts? With no downtime? Without impacting the schedule of whatever software you actually run on these hosts? Don't they got daily updates? are they network exposed? Don't they jump LTS neither never? Not in my experience. For example, at a recent large server environment that I worked in, there were several thousand RHEL 4 boxes. These hosts were nearing end-of-life. When they were replaced, the new hosts were planned to run RHEL 5 or maybe RHEL 6. There was never any plan to perform an OS upgrade on the existing hardware. RHEL's support cycle was long enough that the systems never had to be unsupported. That's not what I'm describing at all. Those places can and should upgrade. I'm talking 1 service to 1 host, multiplied by thousands. These are the companies that want LTS support. That companies of that size, may want to help Debian to help them, keeping packages many years supported without being like a debian oldstable php. Maybe that companies may have ALL Debian developers happy and got the LTS as a result, good luck. I agree. Long-term support is not sexy, and it's not something that most FLOSS developers (or developers in general, in my experience) have any interest in working on. The best way that most companies know to motivate them is to pay them. This is why RHEL, Canonical, and other companies charge so much for support contracts. I'm not sure how anybody could motivate a large enough group Debian developers to work on an LTS release. noah signature.asc Description: Digital signature
Re: Any Account Logs In With Any Password
On Mon, Oct 25, 2010 at 05:16:51PM -0400, Brad Tilley wrote: While experimenting with PCI DSS on a default Debian Linux system, I found that when I comment out this line: authrequiredpam_unix.so nullok_secure in /etc/pam.d/common-auth, any account may ssh into the box by typing anything as the password. Is this the desired behavior? I would think that it would fail by default. If no authentication modules are 'required', then no authentication is required. Makes sense to me. noah signature.asc Description: Digital signature
Re: UNS: Debian 4.0 Upgrade Path
On Thu, Jan 21, 2010 at 04:39:14PM +0100, Thiemo Nagel wrote: having read your email concerning the termination of etch security support, I'm looking for an upgrade path for our installation of ~100 machines. Is it planned to start squeeze security support in time to allow a direct 4.0 -- 6.0 upgrade? In general, skipping major versions has never been supported. An upgrade from etch to squeeze should always involve a short stop in lenny. noah signature.asc Description: Digital signature
Re: gmonstart / jvregisterclasses in tons of binaries with commands,malware?
On Wed, Dec 16, 2009 at 05:59:13PM -0500, whereislibertyandjust...@safe-mail.net wrote: Whether I run 'strings' on the binary files or view with vim or gedit, here is what is always seen inside the binaries: __gmon_start__ _Jv_RegisterClasses They're put there by gcc and are perfectly harmless. What makes you suspicious of them in any way? If you inspect these programs or libraries with objdump, you'll see stuff like w D *UND* __gmon_start__ w D *UND* _Jv_RegisterClasses that indicates that these are weak references, meaning that they don't necessarily even do anything. The symbols are basically stubs that can optionally be filled in at linktime but don't need to be. Digging into the gcc source code, it's apparent that __gmon_start__ can be used by some profiling libraries, while _Jv_RegisterClasses has something arcane to do with calling C++ code from Java, or something like that. (Remember that the gcc suite includes a Java compiler and related tools.) You can find all the source in the gcc source tree. You may not see these symbols on OpenBSD systems because they don't include Java or gprof support in the gcc builds. That's just a guess, though. I don't know that for sure. I'm all for some healthy paranoia, but really, when faced with the possibilities oh my god, the whole world has been pwned or I must be misunderstanding something, go with the latter. noah signature.asc Description: Digital signature
Re: rootkit not found by rkhunter
On Thu, Oct 08, 2009 at 09:08:31AM +, Jörg Sommer wrote: You need to make sure that the machine actually gets rebooted when security updates are made. I thought for security fixes in modules it's enough to update/replace the module. Isn't it? No. If the module is already loaded in memory, then overwriting the file isn't going to help. The vulnerability is in memory. Of course, if the module is not actually loaded, then ovewriting the file is OK. noah signature.asc Description: Digital signature
Re: rootkit not found by rkhunter
On Sun, Oct 04, 2009 at 11:44:52AM -0400, Thomas Krichel wrote:
this looks like a standard privilege escalation (not a rootkit). it
appears to be using one of the recent null pointer dereference kernel
vulnerabilities. your fricka machine is probably running one of the
unpatched kernels ('uname -r' will tell you which version you are
currently running). chichek is up to date since it is preventing
the dereferenced pointer from accessing mmap.
H, here is a of machines affected and unaffected, with
their kernel version
affected
fricka 2.6.26-2-686
...
The kernel version reported by uname is not enough to determine the
security status of the kernel. The kernel version number only changes
when the kernel ABI changes. Security updates are often applied
without ABI bumps. For example, kernel 2.6.26-2-686 was introduced by
linux 2.6.26-14. However, the current version is 2.6.26-19. Several
securty fixes were introduced in the various releases between those two
versions, yet the version reported by uname was unchanged. You need to
make sure that the machine actually gets rebooted when security updates
are made.
AFAIK, the best way to know if you're running a stale kernel is to
compare the uptime of the machine against the mtime of the actual kernel
(using, e.g. stat /boot/vmlinuz-2.6.26-2-686). If the uptime of the
machine places the last reboot sometime before the kernel was updated,
you're not up to date. If there's a better way to test this, I'd love
to know about it.
noah
signature.asc
Description: Digital signature
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Thu, Jul 09, 2009 at 06:02:37PM +0200, Peter Jordan wrote: If you have Kerberos, why would you use ssh keys? GSS-API is so much nicer if you already have a Kerberos environment. And how to login passwordless from outside the kerberos network? There's no such thing as outside the kerberos network. noah signature.asc Description: Digital signature
Re: HEAD's UP: possible 0day SSH exploit in the wild
On Wed, Jul 08, 2009 at 02:03:57PM -0700, Roger Bumgarner wrote: As far as I know, it does keys first then falls back to passwords. I'd imagine PAM could help, but I'm not knowledgeable enough in regards to that. I know you're only limited by your imagination when it comes to PAM authentication. SSH-keys can (and should!) be password-protected already. One of the big problems with ssh keys, though, is that there's no way for an admin to force a user's key to be password protected. On occasion, when there are other restrictions in place, passwordless keys are a good thing and can be used safely, but when used to access a user's account, they're always bad. Also, since ssh public key auth isn't handled by PAM, I don't believe there's a way to use PAM to require both keys and passwords. I could be wrong, though. My users would shoot me if I ever tried such a thing. (Plus we've got Kerberos and don't usually mess around with keys or passwords). Not that any of this will help if this alleged sshd vulnerability can be triggered prior to authentication. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver
On Wed, Jul 09, 2008 at 06:10:51PM +0200, Wolfgang Jeltsch wrote: At this time, it is not possible to implement the recommended countermeasures in the GNU libc stub resolver. I don???t have bind9 installed. Am I affected by the libc stub resolver bug? Yes. I suggest that you install bind9, configure it to only listen on 127.0.0.1, and add nameserver 127.0.0.1 to resolv.conf before any other nameserver lines (since they're queried in order). The following workarounds are available: 1. Install a local BIND 9 resoler on the host, possibly in forward-only mode. BIND 9 will then use source port randomization when sending queries over the network. (Other caching resolvers can be used instead.) 2. Rely on IP address spoofing protection if available. Successful attacks must spoof the address of one of the resolvers, which may not be possible if the network is guarded properly against IP spoofing attacks (both from internal and external sources). Is it okay to apply only workaround 2? Is my server guarded properly against IP spoofing attacks (both from internal and external sources) if the content of /proc/sys/net/ipv4/conf/all/rp_filter is 1? rp_filter doesn't actually do anything meaningful on single-homed machines. All it does is drop inbound packets from host H on interface A if, to reach H, the kernel would send a packet out interface B. It doesn't magically protect against IP spoofing (if it was that easy, then IP spoofing wouldn't be an issue). If you've only got one interface, it doesn't do anything. noah signature.asc Description: Digital signature
Re: ssh-vulnkey and authorized_keys
On Thu, May 15, 2008 at 11:08:58AM +0300, Mikko Rapeli wrote: It would be also helpful to print the line as dokuwd.pl does. Is there any repository with newer versions of ssh-vulnkey or dokuwd.pl ? Try the Ubuntu version which contains a fixed ssh-vulnkey ( http://www.ubuntu.com/usn/usn-612-5 ): Matt Zimmerman discovered that entries in ~/.ssh/authorized_keys with options (such as no-port-forwarding or forced commands) were ignored by the new ssh-vulnkey tool introduced in OpenSSH (see USN-612-2). This could cause some compromised keys not to be listed in ssh-vulnkey's output. I think, and hope, Debian openssh packages will be updated too. Yes, expect it within hours. noah signature.asc Description: Digital signature
Re: openssl/openssh fixes for lenny (testing)
On Wed, May 14, 2008 at 10:39:10AM -0700, Harry Edmon wrote: Are there any plans to issue the same openssl/openssh security fixes for lenny has have been done for etch? OpenSSL has already been fixed in lenny. The openssh package containing ssh-vulkey should hit testing tomorrow at the latest, according to http://packages.qa.debian.org/o/openssh.html noah signature.asc Description: Digital signature
Re: securing server
On Fri, May 09, 2008 at 05:54:40AM -0700, phobot wrote: On May 7, 1:10 pm, martin f krafft [EMAIL PROTECTED] wrote: use integrit/aide/tripwire only useful with read-only media OK, I don't get it if the media is read-only none can alter it so you don't really need tripwire. But if the media is writable so changes can be made you need to run tripwire to check your files. Where am I wrong? What madduck is saying is that tools like tripwire are only useful if you store their databases on read-only media. Otherwise the same attacker who compromised your system could modify the database to cover their tracks. At least tripwire has the ability to encrypt its database, which helps to mitigate this problem. The claim that tripwire is only useful with read-only media is too strong; it can be quite useful without it. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1565-1] New Linux 2.6.18 packages fix several vulnerabilities
On Mon, May 05, 2008 at 02:57:34AM +0200, Peter Palfrader wrote: On Mon, 05 May 2008, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: Apropos. Is there a way to get that information from a vmlinuz file on disk? Without booting it, that is. Interesting enough my (somewhat older) file command does only print x86 boot sector, but I think some magic files supported it. Otherwise you can use strings vmlinux | fgrep 2. I usually use the file name to describe it. debian.org kernel packages don't however. Which makes it not exactly suiteable for a nagios check for is the running kernel the one on the fileystem. I compare the ctime of the kernel image on the system with the machine's uptime. It's the machine's been rebooted since the kernel image changed, we're up to date, otherwise we're still running an older kernel. The attached shell script shows how. You should be able to do this with a nagios check... noah stale-kernel.sh Description: Bourne shell script signature.asc Description: Digital signature
Re: Is oldstable security support duration something to be proud of?
On Mon, Mar 10, 2008 at 01:36:46PM -0500, Filipus Klutiero wrote: I reported #468765 about a questionable statement on www.debian.org. Frank Lichtenheld wants this to be discussed. This statement is in a security announcement. Martin Schulze confirmed that he wrote the statement. Does the security team think that oldstable security support duration is something to be proud of? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468765 I think you misunderstand our policies. You claim in your bug report that Ubuntu, for example, supports a distribution for 1.5 years, while we only support it for 1 year. That is incorrect. Sarge (oldstable) was originally released in early June, 2005. By the time support is retired at the end of this month, it will have received nearly 3 full years of support. We do this for *every* release, too, not just for some LTS releases. Try getting security support for Ubuntu Breezy Badger. It was released 4 months after sarge, but support was terminated 11 months ago. You're damn right we're proud to be able to support a release for 3 years. noah signature.asc Description: Digital signature
Re: Is oldstable security support duration something to be proud of?
On Mon, Mar 10, 2008 at 04:33:53PM -0400, Filipus Klutiero wrote: Their public one, the one you referenced. Argh. If I'm asking about a statement, that's because I read it. Obviously, the author didn't bother checking whether he was right, which is why I'm asking whether there are some people that disagree. The author of that public statement, being a member of the security team, was speaking on the teams behalf when he said that The Debian project is proud to be able to support its old distribution for such a long time... Why should you care if anybody disagrees? I don't care if you think we shouldn't be proud. We are and we will continue to be. noah signature.asc Description: Digital signature
Re: DSA-1494-1 - Graphics errors
On Thu, Feb 21, 2008 at 01:16:33PM +0100, Thomas Hungenberg wrote: I am a little bit surprised that - apart from small graphics errors and some performance issues - the fglrx driver runs fine without the kernel module. I thought that starting x.org would fail if the kernel module is not available. fglrx is OK without its kernel module, though you don't get GL accelleration. The proprietary nvidia drivers, OTOH, don't work without their kernel half. noah signature.asc Description: Digital signature
Re: [DSA 1494-1] Still vulnerable?
On Wed, Feb 13, 2008 at 06:23:16PM -0200, Martin Spinassi wrote: I just upgraded my linux-source-2.6.18 to 2.6.18.dfsg.1-18etch1_all and build a new linux-image. But after installing an rebooting I still was able to become root with this exploit: http://milw0rm.com/exploits/5092 Can anyone reproduce this? Not in our tests. Are you sure you're running the new kernel? What does uname -a say? Has this machine been upgraded from sarge? Then you need to edit /etc/kernel-img.conf to adjust the path to update-grub (or just use update-grub without path). I'm using stack kernel in debian etch, upgraded daily, and still vulnerable. $ uname -a Linux kr0sty 2.6.22-3-486 #1 Mon Nov 12 07:53:08 UTC 2007 i686 GNU/Linux Eh? 2.6.22 isn't in etch at all. Etch includes 2.6.18. noah signature.asc Description: Digital signature
Re: [DSA 1494-1] Missing update for user-mode-linux (was: [SECURITY] [DSA 1494-1] New linux-2.6 packages fix privilege escalation)
On Tue, Feb 12, 2008 at 04:09:00PM +0100, Nicolas Boullis wrote: I think this package deserves an official upgrade. It'll get one. The severity of the issue dictates that we release kernel builds for the various architectures as soon as we get them, rather than waiting until they're all ready. As you'll not from reading the advisory announcement, not all architectures were released initially. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Fri, Jan 11, 2008 at 01:24:28AM -0500, Thomas Bushnell BSG wrote: If a security bug were found in the afs client-side package, which is implemented as a kernel module, would the announcement not look just like the one we saw for DSA 1458-1? See for yourself: http://www.debian.org/security/2007/dsa-1271 noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Fri, Jan 11, 2008 at 12:53:08PM -0500, Joey Hess wrote: Noah Meyerhans wrote: We mention all the binary packages in the advisory because they're the versions that are going to be installed by apt* and people are going to want checksums, file sizes, etc. .. For no good reason, since apt checks all those things for you. That information is a confusing relic, and could be removed from the advisory templates. I agree, but there's no concensus within the security team about this. The argument is that not all sites can or choose to use apt to install updated packages, and that we should make it reasonably convinent for these sites to verify package integrity via other means. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Thu, Jan 10, 2008 at 05:29:18PM -0500, Thomas Bushnell BSG wrote: This is not sufficient advice for how to upgrade. Merely installing a new version of openafs-modules-source will not build it. Some form of m-a invocation as well will be necessary. Except that the security flaw is in the fileserver, which does not involve the kernel module at all and runs fine even without it installed. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1458-1] New openafs packages fix denial of service vulnerability
On Thu, Jan 10, 2008 at 11:25:07PM -0500, Thomas Bushnell BSG wrote: Except that the security flaw is in the fileserver, which does not involve the kernel module at all and runs fine even without it installed. Surely. But then the security update shouldn't mention unaffected packages! All binary packages built from a given source package are updated together. Yes, this is inefficient when many binary packages are built from a single source packages. We mention all the binary packages in the advisory because they're the versions that are going to be installed by apt* and people are going to want checksums, file sizes, etc. We don't have any sane mechanism for updating a subset of a source package's binary packages. Until we do (don't hold your breath) we will continue to provide all the information we're currently providing. Surely you must have wondered in the past why a DSA for xfree86 required you to install new fonts... noah signature.asc Description: Digital signature
Re: netstat shows strange output
On Sun, Jan 06, 2008 at 01:36:26PM -0600, William Twomey wrote: I also disabled ipv6, which I was seeing a lot of from this host. Probably not, unless you've knowingly configured IPv6 routing and all that; you were probably seeing a lot of IPv4 mapped v6 addresses, which look (in netstat) like :::66.116.125.131. [1] Disabling v6 is an entirely reasonable thing to do if you don't use it, but is probably not going to do anything about the actual traffic. tcp0 0 192.168.1.240:www ba.2c.5646.static:55674 FIN_WAIT2 tcp1 0 192.168.1.240:www ba.2c.5646.static:44413 CLOSE_WAIT tcp0 0 192.168.1.240:www ba.2c.5646.static:59517 ESTABLISHED tcp1 0 192.168.1.240:www ba.2c.5646.static:44401 CLOSE_WAIT I've blocked this IP (resolves to 18255.com) on this machine using iptables -I INPUT -s 66.116.125.131 -j DROP This doesn't work, so perhaps it's a spoofed IP? *shrugs* Any help would be appreciated, this is causing a bit of strain on my web server. :/ Dropping packets from a host won't magically make all open connections from that host go away. These connections will eventually time out and go away. Until then, unless your web server is *really* resource-starved, these connections aren't causing any significant strain. You should probably read the netstat man page and RFC 793 [2] for info about what those various states mean. For example, a connection in FIN_WAIT2 state is waiting for a packet from the remote host, which you've explicitly forbidden. noah [1] http://en.wikipedia.org/wiki/IPv4_mapped_address [2] http://nwww.faqs.org/rfcs/rfc793.html signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1409-1] New samba packages fix several vulnerabilities
On Fri, Nov 23, 2007 at 11:10:09AM +0100, Alfio wrote: (Reading database ... 360460 files and directories currently installed.) Preparing to replace samba 3.0.24-6etch4 (using samba_3.0.24-6etch5_i386.deb) ... invoke-rc.d: dangling symlink: /etc/rc2.d/S91samba dpkg: warning - old pre-removal script returned error exit status 102 dpkg - trying script from the new package instead ... invoke-rc.d: dangling symlink: /etc/rc2.d/S91samba dpkg: error processing samba_3.0.24-6etch5_i386.deb (--install): subprocess new pre-removal script returned error exit status 102 Errors were encountered while processing: samba_3.0.24-6etch5_i386.deb I just downloaded through apdet-notifier and the installation went wrong. Then I tried to remove the broken package and install by hand, but it failed It looks like, at some point in the past, you deleted /etc/init.d/samba. This is preventing samba's postinstall script from working, because it expects to be able to call it. If you reinstall samba_3.0.24-6etch5_i386.deb using dpkg -i --force-confmiss the file should be recreated. Note that this will recreate any other conffiles that you might have deleted. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1376-1] New kdebase packages fix authentication bypass
On Fri, Sep 21, 2007 at 04:24:38PM +0100, Steve Kemp wrote: It seems at kdebase and fetchmailconf depencies are broken. I don't see what the source of this is. kdebase: Depends: kappfinder (= 4:3.5.5a.dfsg.1-6etch1) but 4:3.5.5a.dfsg.1-6 is installed. kappfinder is a binary coming from the kdebase package. Check i386. The security archive does not seem to have a complete set of i386 binary packages... noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1376-1] New kdebase packages fix authentication bypass
On Fri, Sep 21, 2007 at 04:48:34PM +0100, Adam D. Barratt wrote: I'm guessing the people reporting problems are i386 users. kdebase: Depends: kappfinder (= 4:3.5.5a.dfsg.1-6etch1) but 4:3.5.5a.dfsg.1-6 is installed. kappfinder is a binary coming from the kdebase package. kdebase is arch:all and therefore installable on i386. kappfinder isn't and there aren't any i386 binary packages for it available. This problem is being worked on right now and will be corrected as soon as possible... noah (for the security team) signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1291-1] New samba packages fix multiple vulnerabilities
On Wed, May 16, 2007 at 09:39:56PM +0200, Thomas Korber wrote: Moritz Muehlenhoff [EMAIL PROTECTED] writes: Nice work on getting this out. Is sarge going to get an update, is it even affected? I've looked into CVE-2007-2444, and http://www.securityfocus.com/bid/23974/ says that the version in sarge is affected. Sarge is still missing a few builds. And what about updated packages for sparc and arm? My samba daemon runs on an old Ultra 60... :-) For the moment you may be better off without the update. See e.g. bug 424629. (obviously if you machines get rooted then this isn't much help...) noah signature.asc Description: Digital signature
Re: spooky windows script
On Tue, May 08, 2007 at 05:34:30PM -0400, Gerardo Curiel wrote: El mar, 08-05-2007 a las 22:24 +0200, Thomas Hochstein escribi?: Chris Adams schrieb: Do you have a VNC server installed? | But I do have vino-server running. That's the problem, the same happened to me a couple of weeks ago, in my Desktop(a newly installed Debian Unstable). Vino seems to open the vnc port to the outside without password when installed by default. No, vino doesn't do anything by default (just confirmed in sid). What do you have configured in System - Preferences - Remote Desktop ? By default, nobody can connect at all. Clicking on the only initially active checkbox (Allow other users to view your desktop) results in a configuration where other users can connect, but they can't actually view or control your desktop until you've approved their connection via a popup dialog. If you uncheck Ask you for confirmation and neglect to check Require the user to enter this password and provide a password, then it seems that unauthenticated, unapproved connections are allowed. IMO this should never ever be allowed, but it is. It's definitely not the default state, though. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1285-1] New wordpress packages fix multiple vulnerabilities
On Tue, May 01, 2007 at 11:18:22AM -0700, Michael Leibowitz wrote: The DSA incorrectly identifies etch as the unstable distribution. Yeah, my fault. The web site will have it listed correctly, of course. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1258-1] New Mozilla Firefox packages fix several vulnerabilities
On Wed, Feb 07, 2007 at 04:38:30PM +0100, Holger Levsen wrote: Lalala WTF? At least you used a proper from:-header... Could you *please* correct your errors (which are no problem per se) correct in a professional way? The errors have already been corrected: http://www.debian.org/security/2007/dsa-1258 noah signature.asc Description: Digital signature
Re: texinfo update?
On Sun, Nov 26, 2006 at 12:47:55AM +0100, Alexander Klauer wrote: there has been a texinfo update for sarge available from security.debian.org for a few days now. The changelog in the source package says something about arbitrary code execution. The GPG signature by Noah Meyerhans is good, as are the MD5 sums. Yet, I cannot find any accompanying advisory on this mailing list or on http://www.debian.org/security/. Why? There's a revision of the security update on its way that fixes another vulnerability that I discovered when preparing the DSA text for 2.2sarge1. Technical issues within the buildd network (an overloaded arm build machine and a failed MIPSel build machine) have delayed this. I hope to release -2.2sarge2 within the next 24 hours, along with a DSA. noah signature.asc Description: Digital signature
Re: Remote Root In Nvidia xserver Driver
On Wed, Oct 18, 2006 at 02:11:24AM +0100, paddy wrote: NB: although some are saying this is a local root exploit only, the bulletin points out it can be exploited by visiting a malicious webpage. I've not scrutinised the claims closely, but it looks like a remote vulnerability to me :-( The original(?) announcement of the vulnerability, http://download2.rapid7.com/r7-0025/ , states that the problem can be exploited as a DoS remotely via e.g. a specially crafted web page (an example of which they've graciously provided). However, as I read it, it sounds like you can only run arbitrary code if you are actually accessing the X server directly via a client. While this client can be local or remote, nobody is going to allow unauthenticated remote clients to access their X server, so this might not be so bad... Presumably this is because it's not practical or feasable to provide the actual shell code you want to jump to if you're only controlling an HTML document. If you're controlling the actual X client, it might be more reasonable. Of course, this may allow an attacker to leverage one of the many Firefox exploits to run code as root... Naturally, I could be wrong. noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1195-1] new openssl096 packages fix denial of service
On Tue, Oct 10, 2006 at 09:22:43PM -0400, David Kennedy CISSP wrote: signed by a key not included in http://www.debian.org/security/keys.txt and not on the PGP.COM, MIT.EDU or any other of several public key servers. It's on pgp.mit.edu (http://pgp.mit.edu:11371/pks/lookup?search=noahm%40debian.orgop=index) and db.debian.org. I'll see about updating http://www.debian.org/security/keys.txt ASAP. noah signature.asc Description: Digital signature
Re: OpenSSL: RSA Signature Forgery (CVE-2006-4339)
On Wed, Sep 06, 2006 at 06:14:51PM +0200, Allard Hoeve wrote: Please take note of: http://www.openssl.org/news/secadv_20060905.txt Acknowledged. A fix is already in the works. noah signature.asc Description: Digital signature
Re: When are security updates effective?
On Tue, Aug 29, 2006 at 10:54:45PM +0200, Moritz Muehlenhoff wrote: If there's anything special to do (e.g. kernel or glibc) we alredy add this to the DSA text. I don't think that's quite enough. I have a few hundred Debian workstations for which I'm responsible, and it's difficult for me to make sure that the users e.g. restart firefox when we release an update. Daemons automatically get restarted, but desktop apps require intervention. In my case, the desktop apps aren't being run by the people installing the updates (the updates are typically installed either remotely or fully automatically) and that makes things even more difficult. I haven't come up with a really good solution to this problem. I actually sort of like the Windows method of incessantly nagging the user to reboot their machine (it literally pops up a dialog box every few minutes). I like the idiot-proof factor. Yes, they can ignore the popups, but they come so quickly that even the most stubborn user will get sick of them and reboot. I'd hate it if I was a Windows user, though, I'm sure! noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 1111-1] New Linux kernel 2.6.8 packages fix privilege escalation
On Mon, Jul 17, 2006 at 06:13:28PM +0200, Moritz Muehlenhoff wrote: This was an error on my side, it's already corrected on the web: http://www.debian.org/security/2006/dsa- Any idea why this DSA isn't linked to from http://www.debian.org/security/ ? The document is there, but there's just no link. noah signature.asc Description: Digital signature
Re: Debian Kernel security status?
On Wed, Apr 19, 2006 at 03:56:41PM -0600, Michael Loftis wrote: Increasingly 2.6 is unsuitable for production use due to its huge amount of change and lack of stable tree. There was a decision to do away with the old split development/odd numbered development model sometime after about 2.6.11 so all hope of a stable 2.6 series is gone. Speaking as the admin of a large (several hundred hosts) Debian installation, I agree. Hopefully something will come of http://kerneltrap.org/node/6386 Speaking as a Security Team secretary, you should not treat all kernel CVEs as equal. Many of them are low priority information leaks, hard to exploit DoS attacks, or only effect obscure hardware. Many of them affect only a very few users or are only exploitable in theory. None of them are being widely exploited. Rest assured that, if a remote root exploit is discovered in the kernel tomorrow, we'll have a fix out promptly. I don't mean for the above to be interpreted as though the Debian security team does not take kernel security seriously. That's quite the opposite. However, releasing a new kernel update for every CVE that comes out is really not in anybody's interest. noah signature.asc Description: Digital signature
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
On Thu, Dec 15, 2005 at 12:35:09PM +, kevin bailey wrote: the service: 443/tcp open https is used to protect the webmail service. it is meant to stop the email passwords from being sniffed. If you're concerned about passwords being sniffed, you better shut off pop3 and imap, too (unless you configure IMAP such that plaintext passwords will never be prompted for, which should be possible according to section 6.2.2 of RFC 3501). In the case of pop3, it is not possible to configure secure authentication mechanisms, and you should switch to the SSL-tunnelled pop3s if you really need POP support. what is 1720/tcp filtered H.323/Q.931 ? and how do i turn it off if it is uneccessary. It may be nothing. The fact that it showed up as filterd in the nmap output indicates that nmap didn't received a TCP RST packet back when it tried to contact that port. That may mean you have iptables configured to DROP packets to that port. noah signature.asc Description: Digital signature
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
On Thu, Dec 15, 2005 at 06:46:02PM +0100, Florian Weimer wrote: It may be nothing. The fact that it showed up as filterd in the nmap output indicates that nmap didn't received a TCP RST packet back when it tried to contact that port. That may mean you have iptables configured to DROP packets to that port. It could also mean that the the ISP filters 1720/TCP, in order to prevent its customers from using VoIP. Good point. I suspect that's more likely. noah signature.asc Description: Digital signature
Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931
On Thu, Dec 15, 2005 at 10:19:48PM +, kevin bailey wrote: good point - also the fact that the users stick their email passwords to their monitors using postits! Well, at least there's still *some* level of physical security there; an attacker has to be at your user's desk to get the password. Plus, given the choice between having your users use weak but easy to remember passwords and having them use complex passwords that they have to write down, the latter is the better option. I'd suggest that they keep their password in their wallet or something, though, and only take it out when they need it. Treat it like a credit card or something, and it's basically safe. i'm almost thinking to switch the webmail service to normal apache - this would save me from having to run apache-ssl altogether. the email accounts are virtual accounts and are not system/FTP accounts run on a courier email server. Apache+mod_ssl is the way to go. If your users will only access their mail via the web interface, then configure your your IMAP server to only listen on the loopback interface. It may be nothing. The fact that it showed up as filterd in the nmap output indicates that nmap didn't received a TCP RST packet back when it tried to contact that port. That may mean you have iptables configured to DROP packets to that port. iptables has not been set up - but i take what you say. so if i set up a firewall and drop nearly all packets does nmap report ports as unfiltered? ^^ You mean filtered. Yes. Normally, when a TCP SYN is sent to a port with nothing on it, the OS sends back a TCP RST packet, basically saying there's nothing here. If you configure iptables to DROP the packets, then nmap realizes that it didn't get the RST back and lists the port as filtered. If you want to firewall off a port such that it appears to the outside world that there is nothing on that port at all, use -j REJECT --reject-with tcp-reset in the iptables rule. As Florian pointed out, though, it's likely that your ISP is actually dropping the SYN packet, and that's why nmap isn't getting the RST back. Your OS never sees the SYN at all so it never sends back the RST. noah signature.asc Description: Digital signature
Re: What is a security bug?
On Wed, Nov 23, 2005 at 12:59:02PM +0100, Florian Weimer wrote: Availability is typically considered one aspect of security (and arguably the hardest one to get right in networked applications). I tend to consider it the other way around. Security is a subset of availability. Availability must also take in to account things like hardware failures, network problems, software configuration, etc. It also must account for security. As a sysadmin, my primary interest is not in the security of my services (if it was, I'd unplug them all!), but in the availability. Because security is one aspect of availability, I must account for it when designing and maintaining systems, but it can't be the ultimate goal, since a truly secure system provides no availability. noah signature.asc Description: Digital signature
Re: Is there a known rpc.statd buffer overflow?
On Wed, Nov 09, 2005 at 10:28:53AM -0500, Kevin B. McCarty wrote: I received the following (see below) in an email from logcheck on my home desktop running Sarge. Looks like an attempt to cause a buffer overflow in rpc.statd. System logs don't include anything else that looks suspicious. That's a *really* ancient bug. It was fixed long before woody (yes, woody) was released. It is pretty amazing that such ancient worms are still in the wild... I'm almost surprised that we aren't still seeing occasional signs of the Morris Worm trying to propagate. ;) noah signature.asc Description: Digital signature
Re: [SECURITY] [DSA 866-1] New Mozilla packages fix several vulnerabilities
On Thu, Oct 20, 2005 at 07:22:30AM -0400, Baxley, Dewayne (ISS Atlanta) wrote: Please unscribe me from this list. Thanks! Instructions for unsubscribing are included at the bottom of every message posted to the list. Please follow them. noah signature.asc Description: Digital signature
Re: security.debian.org mirrors?
On Thu, Sep 29, 2005 at 09:50:34PM +0200, Arnaud Fontaine wrote: Is it possible to have a warranty that the package in the mirror archive hasn't be modified by someone else ? Maybe my question is stupid but i wasn't able to find an answer on replicator website ;). Is this really more important in the security archive than in the main archive? I do not believe it is, since any package, whether in the security archive or not, is going to execute code as root on your machine. But anyway, the MD5 checksums and file sizes for the updated package files are included in the DSA. Thus, you have plenty of information to verify the package integrity if you need to. noah signature.asc Description: Digital signature
Re: security.debian.org timeouts
On Mon, Sep 19, 2005 at 09:18:29PM +0200, No?l K?the wrote: anybody knows what's the problem with klecker/security.d.o? The whole day I get timeouts but I could update xfree(woody)/xorg(sarge) on some machine but I didn't find the DSA for it. Any information about this? See http://lists.debian.org/debian-curiosa/2005/09/msg00018.html klecker is having difficulty keeping up with the load caused by the X packages being updated. Not much else to do but wait. There may be a long-term solution to this type of problem forthcoming, but it's not available yet and there are many details to be worked out, so it isn't ready to be announced just yet. noah signature.asc Description: Digital signature
Re: security.debian.org timeouts
On Mon, Sep 19, 2005 at 10:45:37PM +0200, Bartosz Fenski aka fEnIo wrote: I wonder what else should I read to keep in touch with such important information? slashdot? ;) signature.asc Description: Digital signature
Re: On Mozilla-* updates
On Tue, Aug 02, 2005 at 10:09:13AM -0700, Thomas Bushnell BSG wrote: IMHO, sloopy security support (by uploading new upstream versions) is better than no security support. Are you prepared to make sure all the packages that depend on mozilla will have packages ready to enter at once? Are you prepared to kick all packages that depend on mozilla out of Debian completely? How about actually maintaining them? That's exactly what I think we should do. That's the choice we've got. Moving them to backports.org or volatile, which are not carried by the mirror network, not included in the default apt sources.list, and not getting DSA announcements, IMHO, counts as kicking them out of Debian. Oh, I see. I think the whole point of volatile is that it is *part* of Debian. Except that it isn't, for all the reasons I described. Users will not see packages in volatile unless they go out of their way to reconfigure apt, they will not receive DSA announcements regarding new versions of packages there, and the archive is not carried by the standard Debian mirrors. Can a bug be closed by an upload to volatile? noah signature.asc Description: Digital signature
Re: On Mozilla-* updates
On Tue, Aug 02, 2005 at 09:56:12PM +0200, Petter Reinholdtsen wrote: [Noah Meyerhans] How about actually maintaining them? That's exactly what I think we should do. Is this we as in you, or we as in someone else? We as in all of us who have been suggesting that we allow e.g. firefox 1.0.6 into stable. We as in those of us who are frustrated and don't want to put any work into this based on Joey's clearly stated intent to disallow new upstream versions to be used for security updates or to be included with stable revisions, no matter what noah signature.asc Description: Digital signature
Re: On Mozilla-* updates
On Mon, Aug 01, 2005 at 04:57:31PM -0700, Thomas Bushnell BSG wrote: IMHO, sloopy security support (by uploading new upstream versions) is better than no security support. Are you prepared to make sure all the packages that depend on mozilla will have packages ready to enter at once? Are you prepared to kick all packages that depend on mozilla out of Debian completely? That's the choice we've got. Moving them to backports.org or volatile, which are not carried by the mirror network, not included in the default apt sources.list, and not getting DSA announcements, IMHO, counts as kicking them out of Debian. noah signature.asc Description: Digital signature
Re: On Mozilla-* updates
Most other OS vendors are willing to make updates for errata beyond simple security updates. Often this means minor updates to software packages like web browsers. I believe the community will be better able to help us prepare e.g. bug-free firefox 1.0.5 packages than it will to produce 1.0.4+security packages. I believe these updated packages should be tested as thoroughly as possible and released via security.debian.org and included in the next sarge revision. As an administrator of several hundred Debian workstations, all of which include mozilla, firefox, and thunderbird, I can say that I'd rather see 1.0.5 than see nothing at all, or (IMO just as bad) unofficial packages distributed outside the official Debian update channels. Whatever solution we choose, I believe it is very important for us to do it within Debian and not rely on backports or some other unofficial channels. As Debian developers, it is our duty to solve this problem, and simply kicking the packages out of Debian or ignoring them from the point of view of updates and security is really no solution at all. noah signature.asc Description: Digital signature
Re: Bad press related to (missing) Debian security
On Mon, Jun 27, 2005 at 11:26:37AM -0700, Matt Zimmerman wrote: The security team has always been a difficult one to expand. A strong level of trust is necessary due to confidentiality issues, and security support is a lot of (mostly boring and thankless) work. However, expanding it seems like the only way to make it sustainable. Even allowing uploads from the secretaries could be helpful. Steve Kemp has done a lot of good work in his role as secretary (much more than I've ever done). In cases where Joey is offline for an extended period of time, having Steve or myself perform uploads might make the most sense. We already have some state WRT the current issues, and have all the same patches that Joey has. It's mostly a matter of coordinating releases with other vendors and making sure that the newly released package has the right changes applied and has a sane version number. Part of the problem with security updates has to do with the fact that it's just difficult to coordinate the work. Even when Wichert, mdz, and others were more active, Joey still did most of the work because it was often easier for one person to keep track of everything. The secretary position was originally created to help this situation, but it was never really clear to me what my role was supposed to be. noah signature.asc Description: Digital signature
Re: Bad press related to (missing) Debian security
On Mon, Jun 27, 2005 at 09:05:53PM +0200, martin f krafft wrote: How much information can be disclosed about the inner workings of the security team without damage? Most, but not all, of the security team's work is rather routing and very uninteresting. Often it is necessary to review code and verify that it does actually fix a given problem. That can be very difficult, and is often made more difficult by the fact that we're dealing with older and no longer supported upstream versions. Package maintainers are routinely enlisted to help with the process, though, under the assumption that they are more familiar with the code than is the security team. IMHO, the security secretaries should be the ones keeping track of builds and releasing DSAs once all the packages are updated. This doesn't require any particular skill, and is ideally suited to the roll of a secretary. (though, when trying to do that kind of work, I've always found that I'm a whole lot better at hacking than I am at secretarial work; I suspect that's the case with a lot of developers) noah signature.asc Description: Digital signature
Re: Empty /root/.bash_history
On Thu, Jun 23, 2005 at 09:21:14AM +0200, anders alm wrote: This has happened twice for me, first on an old mdk dist, so i went paranoid and upgraded to debian, and a few weeks ago my /root/.bash_history was empty again! Can it be something other than a break in? The partition /root lies on has plenty of space so it's not because of that. Any ideas/suggestions? Hi Anders. I've seen this kind of thing happen a couple of times when bash exited uncleanly or unexpectedly. I'm not sure of the details, but it is not *necessarily* indicitive of a security issue. Spend a little bit of time examining your system (chkrootkit, debsums, etc), and, if you don't find anything and don't notice any sort of strange behavior, you can probably assume there's nothing wrong. noah signature.asc Description: Digital signature
Re: Darn skiddies (ssh login attempts)
On Thu, Mar 31, 2005 at 10:44:53PM -0600, Brad Sims wrote: `less /var/log/auth.log|grep Failed|wc -l` shows 185 attempts to compromise my machine since March 27th... A similar command on the log server on a class B network (/16) shows 1482 such attempts in the past 19 hours or so. It's just a worm, and unless you've got a weak password policy, you don't have anything to worry about. Eventually you just get used to it. There's really not a whole lot that can be done to prevent it. /etc/hosts.deny reads: ALL: ALL /etc/hosts.allow reads: sshd: $WORK_IP1 sshd: $WORK_IP2 Will not having the usual all: local break something? Almost certainly not. Unless you routinely ssh to localhost. noah pgpHVhHWyIQlU.pgp Description: PGP signature
Re: My machine was hacked - possibly via sshd?
On Tue, Mar 29, 2005 at 01:38:55PM +0100, Simon Heywood wrote: Sorry, but this isn't correct. kernel 2.4.18-1 in woody is patched against known vulnerability. The security team have quietly stopped updating it, preferring to concentrate on the Sarge kernels. The security team does not currently support the sarge kernels in any way. They are still in the hands of the Debian kernel package maintainers. It would be utterly rediculous to drop support for anything in the offical Debian release in favor of an unreleased development version. Some of them, maybe. But take a look at #289708 for an example of an unfixed vulnerability in Woody's 2.4.18. The security team is aware of the outstanding vulnerabilities in woody's kernels. Unfortunately, due to the fact that woody's kernel situation is a complete mess, the updating of kernel packages is very labor intensive. Since there's only one developer actively working on security updates right now, it's difficult to keep up. Fortunately, sarge will greatly improve the kernel security situation, and it will not be as difficult to support sarge's kernels as it currently is with woody. noah pgpuIAMeT9zhb.pgp Description: PGP signature
Re: My machine was hacked - possibly via sshd?
On Wed, Mar 30, 2005 at 07:16:31AM +1000, David Pastern wrote: And this, in reality, is why Woody is so old. I cannot imagine any other distro providing such an old kernel. You've got cause and effect mixed up. Debian is not outdated *because* we support ancient versions of software. We support ancient versions of software because we are outdated. No distribution provides support for their development branch before their stable branch. It's not like Debian isn't aware of it's excruciatingly slow release cycle, either. See http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html for evidence of some rather drastic changes being considered in an attempt to fix the problem. noah pgpH4WRTbni7K.pgp Description: PGP signature
Re: My machine was hacked - possibly via sshd?
On Mon, Mar 28, 2005 at 02:41:06PM -0500, Malcolm Ferguson wrote: Machine was running Debian 3.0 and was behind a NAT box with ports forwarded for SMTP, HTTP and SSH. It hadn't been rebooted for 430 days. I was using a 2.4 kernel with MPPE builtin. If it had an uptime of 430 days, there were well known exploitable security problems in the kernel. They were all local exploits, however... Early on the 25th, my logcheck emails indicated increasing messages in syslog concerning failed login attempts against ssh. At some point though I see ssh authentication failures for valid user names - how? Somehow they were being enumerated in the hack attempt, and I think that one person had a weak password. Finally I see an attempt to load net-pf-14 and other modprobe errors. At some point there are also messages about the ethernet card entering promiscuous mode. There are a number of ssh brute-force login worms going around. It's entirely possible you were hit by one of these, and not by an actual human attacker. Once the worm got local access via a weak password, the kernel you were running probably gave them easy access. I've rebuilt the machine. The biggest changes so far have been partitioning. I no longer have a single partition, but about 10, including read-only ones for /usr and /boot. I'm also running the Debian stock 2.4.18-1-586tsc 2.4.18-1-586tsc (I don't need to create PPTP tunnels anymore). I have Exim up and running and exposed to the internet. I need to open up ssh to external connections too soon, and of course I will be reinstalling Apache within a week. Unfortunately, I do believe there are known security problems with Debian's 2.4.18 packages. The kernel source situation in woody makes it rather unpleasant and time consuming for the security team to create updates, and since there's really only one person creating security updates these days, it hasn't gotten done. If I were you, I'd build my own kernel binaries from kernel.org sources, applying whatever patches are needed via either a Debian kernel-patch-foo package (assuming it applies to the newer kernel) or by manually tracking down the patch and applying it by hand. Sample logcheck messages: Mar 25 01:24:19 erin-and-malc sshd[23707]: Did not receive identification string from 193.170.65.132 Mar 25 01:31:02 erin-and-malc sshd[23661]: Did not receive identification string from 203.228.120.102 Mar 25 02:23:12 erin-and-malc PAM_unix[24756]: authentication failure; (uid=0) - backup for ssh service Mar 25 02:23:14 erin-and-malc sshd[24756]: Failed password for backup from 193.170.65.132 port 4128 ssh2 Mar 25 02:24:24 erin-and-malc PAM_unix[24884]: authentication failure; (uid=0) - erin for ssh service Mar 25 02:24:26 erin-and-malc sshd[24884]: Failed password for erin from 193.170.65.132 port 5776 ssh2 This is very common. I see this same stuff all the time. The first couple of messages are the probes of your network (by your I really mean your ISP's) to determine which hosts are actually running sshd. The next are the brute force login attempts. People are undoubtedly going to suggest all kinds of firewall type solutions to this problem. However, I don't think a firewall is going to help you here. In effect, the NAT box you were running was already providing some firewall services, and look what good it did. TCP port 22 and 80 are almost certainly going to be exposed to the internet, whether you're running a firewall or not, so you've really got to take care to make sure those services are secure. In the case of sshd, make sure you've got strong passwords, or better yet make sure that only e.g. ssh public-key authentication can be used. noah Mar 25 04:05:14 erin-and-malc modprobe: modprobe: Can't locate module ppp0 Mar 25 04:05:18 erin-and-malc kernel: request_module[ppp0]: fork failed, errno 1 This looks like the worm may have been trying to establish a ppp connection (probably tunneled over something else, maybe ssh) to somewhere. I'd be interested in knowing where. Mar 25 05:02:04 erin-and-malc kernel: eth0: Promiscuous mode enabled. Mar 25 05:05:13 erin-and-malc kernel: eth0: Promiscuous mode enabled. Typical packet sniffer. HTH, noah pgph14RMLFWrd.pgp Description: PGP signature
Re: secure ident daemon
On Sat, Mar 19, 2005 at 01:35:06PM +0100, LeVA wrote: Can someone please suggest me a secure ident daemon. I can not choose from the apt searched list. What do you mean by secure? None of the ident daemons have any known security vulnerabilities, per se, but the ident protocol itself has no real notion of security. noah pgpHPMauD9Ysi.pgp Description: PGP signature
Re: A tripwire annoyance
On Wed, Oct 06, 2004 at 02:53:19PM +0100, Dale Amon wrote: I've been running tripwire on a particular server for some years and finally got annoyed at skimming through the large reports, so I began an update... After 24 hours I thought it was hung and killed it. I restarted it with verbose and found that it is indeed working. And just for the hell of it, I've left it running to see how long it would take. Which version of tripwire is this? It sounds like behavior I'd expect to see with the ancient ancient ancient version that we shipped prior to woody (there is no tripwire in woody), but I've never seen anything like that with tripwire 2+. How did you perform this update? The right way to do it is to do 'tripwire -m u reportfile', which doesn't actually look at the filesystem at all but simply merges the filesystem data contained in the report into the database. noah pgptqfDUqCJx0.pgp Description: PGP signature
Re: BAHAHA was (telnetd vulnerability from BUGTRAQ)
On Tue, Sep 28, 2004 at 11:15:09AM -0400, Alfie wrote: Assuming the U.S. government doesn't freak out and stop it, IPSEC encryption will soon(?) be used for all internet communication That's the funniest thing I've read in a long time. Unless you mean soon on an astronomical time scale, and even then I think you're being optimistic. noah pgp9x14MRYHeW.pgp Description: PGP signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 02:42:08PM -0400, Dossy Shiobara wrote: Other than blacklisting the IPs (which is a race I am going to lose), Why do you say that? I haven't seen this more than a few times a week so I haven't bothered to do anything yet, but I'm very close to writing a script that tail's the syslog and on more than X repeat failures, add a rule to iptables -j DROP traffic from the offending IP address. I see several of these attempts every day, always hitting sequential IP addresses. When you have dozens of servers that otherwise wouldn't log anything worth a logcheck report, this means lots and lots of unnecessary mail. If I'm feeling nice, I'll keep a list of the IPs that have been temporarily blacklisted with a timestamp of when they were added, and expire them after X time has passed ... I have found it mostly futile to blacklist them at all, unless I catch them as soon as the scanning starts. They hit IP addresses in sequential order, and once they're done scanning my netblock, I haven't seen any more of them. So logcheck, running only once an hour, is useless. It lets me know that such a scan happened, but by the time I get the mail, I don't care. If I notice the scan immediately, I will occasionally blackhole the source IP at our network border, but it's rare that I notice in time. noah pgpQVMcxhr9qu.pgp Description: PGP signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 09:53:23PM +0200, Bernd Eckenfels wrote: You can either move your ssh to another port, that will greatly reduce the distributed brute force attacks, or you can put a filter with port knocking in front of it. Another option is to turn off password authentication, completely. Neither of these is an option at a large site with dozens or hundreds of ssh users. Maybe if the sysadmins are the only ones who care about ssh it's an option, but where's the fun in that? And yes you should be worried about those attacks if you habe weak passwords. That's trivial to fix, even in large sites. Min password lenghts of 8 characters with a minimum of two character classes are going to interfere with any random login based password guessing. Especially since, from what I hear about this scanner that's responsible for all these login attempts, it's trying mind-numbingly simple passwords, like root/root, guest/guest, empty passwords, and things like that. noah pgpQFIu4sdpQp.pgp Description: PGP signature
Re: failed root login attempts
On Sun, Sep 19, 2004 at 10:09:12PM +0200, martin f krafft wrote: These scripts already exist. However, they require you to look continuously. That's not an option. And it has to keep the admin in the loop (and thus not be an automated blocker) because otherwise you are open for denial-of-service attacks. As an additional point against these scripts, they are host based. If I'm going to bother blackholing the source of these login attempts, I'm going to do it at the border. Yes, I can write scripts to react to this kind of scanning and have it automatically manipulate access lists on the routers, I'm not sure I really like the idea. I'm sort of leaning in that direction, at this point, though, just to shut up logcheck without telling it to ignore all failed root login attempts. noah pgphAykCqjpee.pgp Description: PGP signature
Re: [d-security] Re: [SECURITY] [DSA 532-1] New libapache-mod-ssl packages fix multiple vulnerabilities
On Tue, Jul 27, 2004 at 01:42:19PM +0200, Christian Hammers wrote: In my case, the frontend handles SSL connections. Its config file is /etc/apache/ht-light.conf. The backend instance uses the original filename /etc/apache/httpd.conf. The frontend is already bound to port 443. The backend tried to restart, but now has a load mod_ssl line, and can't start. And now our application won't run... Oh, come on, if you apt-get install the Apache SSL module then you really can expect it to actually get installed in the httpd.conf :-) (Otherwise hundrets of normal users would complain that SSL does not work although they installed it. So at least in my opinion the behaviour is ok as special configs will always need attention) The packaging system *can* differentiate between an upgrade and a fresh installation. It's reasonable for the package to do this kind of thing on a fresh installation, but not on an upgrade. This should be a bug in the package in question. I'm somewhat surprised that the package in question is allowed to do what it does at all, considering the working in section 10.7.4 of the Debian policy document: The maintainer scripts must not alter a conffile of any package, including the one the scripts belong to. Additionally, from section 10.7.3: local changes must be preserved during a package upgrade... So I don't really know how the libapache-mod-ssl package gets away with what it's doing at all. noah pgp0sVIqqokTF.pgp Description: PGP signature
Re: [SECURITY] [DSA 532-1] New libapache-mod-ssl packages fix multiple vulnerabilities
On Tue, Jul 27, 2004 at 09:05:22AM -0700, Matt Zimmerman wrote: It is unfortunate that this caused a problem for you, but it was not the resul of the security update. The woody Apache packages have always worked this way, and will modify /etc/apache/httpd.conf. It is worth noting that as of version 2.8.12-2 of libapache-mod-ssl it no longer touches httpd.conf. Refer to the changelog available at http://packages.debian.org/changelogs/pool/main/liba/libapache-mod-ssl/libapache-mod-ssl_2.8.19-1/changelog noah pgpefdIs2rNEh.pgp Description: PGP signature
Re: Patches that break stuff
On Fri, Jul 09, 2004 at 10:53:01AM -0400, Robert Brockway wrote: Are any hard stats available on how many Debian package upgrades have had to be replaced because they broke something? I'm thinking the total number of broken updates in 2.2 and 3.0 is 0 plus or minus 1 :) It's definitely greater than 0. In recent memory (earlier this year), we released a kernel image package that didn't contain any modules. Naturally it was fixed quickly, but I'm sure it lead to at least a couple of unbootable systems. I think there were probably a couple other issues, but I don't know off the top of my head. noah pgpwnJakjRnun.pgp Description: PGP signature
Re: rbl's status?
On Sun, Jun 13, 2004 at 07:46:15PM +0300, Vassilii Khachaturov wrote: What are the recommended rbl's these days? Best thing is ask on NANAE or exim-users or whatever your favourite MTA is. Here's what I am using here RBL-wise: rbl_domains = bl.spamcop.net/reject : relays.osirusoft.com/reject :spamhaus.relays.osirusoft.com/reject : sbl.spamhaus.org/reject You do realize that the osirusoft blacklists are defunct and have been for several months, right? Basing your decision of whether or not to accept mail from a given host based on an answer from a defunct blacklist is probably not a good idea. noah pgpk7x9guu3oQ.pgp Description: PGP signature
Re: rbl's status?
On Sun, Jun 13, 2004 at 07:46:15PM +0300, Vassilii Khachaturov wrote: What are the recommended rbl's these days? Best thing is ask on NANAE or exim-users or whatever your favourite MTA is. Here's what I am using here RBL-wise: rbl_domains = bl.spamcop.net/reject : relays.osirusoft.com/reject :spamhaus.relays.osirusoft.com/reject : sbl.spamhaus.org/reject You do realize that the osirusoft blacklists are defunct and have been for several months, right? Basing your decision of whether or not to accept mail from a given host based on an answer from a defunct blacklist is probably not a good idea. noah pgp1gZDfYRD76.pgp Description: PGP signature
Re: Security for woody after woody-sarge ?
On Thu, Jun 10, 2004 at 02:28:49PM +0100, Alex Owen wrote: I ask as I'm commisioning a woody system and cannot upgrade to sarge till July/August 2005 so I'll probably need a year of woody security updates. I don't think you have much to worry about. The infrastructure is in place and was used to support potato for the year following woody's release. noah pgpZ3xQnO5OgA.pgp Description: PGP signature
Re: Security for woody after woody-sarge ?
On Thu, Jun 10, 2004 at 02:28:49PM +0100, Alex Owen wrote: I ask as I'm commisioning a woody system and cannot upgrade to sarge till July/August 2005 so I'll probably need a year of woody security updates. I don't think you have much to worry about. The infrastructure is in place and was used to support potato for the year following woody's release. noah pgpT5EZtypl0z.pgp Description: PGP signature
Re: restricting process limit
On Mon, Apr 26, 2004 at 06:44:35PM +0200, LeVA wrote: So when I'm getting a large amount of messages there is approx. 15-20 spamc/spamd running. I want to limit this to ~5. How can I do this. The First of all, this is OT for debian-security. It should have gone to debian-user. Second, RTFM. From spamd(1): -m number, --max-children=number Specify a maximum number of children to spawn. Spamd will wait until another child finishes before forking again. Meanwhile, incoming connections will be queued. Please note that there is a OS specific maximum of connections that can be queued (Try perl -MSocket -e'print SOMAXCONN' to find this maximum). Also, this option causes spamd to create an extra pipe for each child. noah pgp8CqKdpe3k6.pgp Description: PGP signature
