Re: Script to System Check Integrity against Debian Package Repository
On 09/17/2013 09:45 PM, adrelanos wrote: Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine. Why not just reinstall from a trusted source, then restore /etc, /home and /var from backups and audit the changes introduced by that only? In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) It is copied from /usr/lib/grub/i386-pc: $ dpkg -L grub-pc-bin | grep video_fb /usr/lib/grub/i386-pc/video_fb.mod - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? Aren't they generated by the package's postinst script? And I have open questions, such as: - Which package is responsible for creating device files (/dev/...)? How to check if they are legit? /dev should just be a tmpfs, so the kernel creates device files there (possibly triggered by udev). $ mount | grep '/dev ' udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1013295,mode=755) - Is there a signed dump of the grub boot sector somewhere? I think it is based on /usr/lib/grub/i386-pc/boot.img, but with some offsets adjusted. Isn't it safer to just re-install grub from your trusted system? Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52395812.9090...@etorok.net
Re: NULL Scan issues or something else?
On 02/08/2013 11:16 PM, Daniel Curtis wrote: Hi Mr Erwan Let's summarize: these logs are normal and are not something... /bad/. Even if there are many IP's connections (/INVALID/) probes. I understand, that I should have not contact with the servers. Okay, but if those servers are providing e.g. a website, which I visit? How to avoid them? I apologize for my naive questions. Do you have an iptables rule like this one *before* the rule that logs/drops your packets? ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51157248.4070...@etorok.net
Re: MySQL Local Crash Vulnerability
On 04/18/2012 11:09 PM, Zachary Schneider wrote: Reference: http://www.h-online.com/open/news/item/Oracle-accidentally-release-MySQL-DoS-proof-of-concept-1526146.html Create crash with: http://bazaar.launchpad.net/~mysql/mysql-server/5.1/view/head:/mysql-test/suite/innodb/t/innodb_bug13510739.test?sort=filename But I guess not. Of course Oracle isn't terribly helpful on the exact fix for the problem... Isn't this the fix? (judging by the commit that added that test file) https://bazaar.launchpad.net/~mysql/mysql-server/5.1/revision/3560.8.4 https://bazaar.launchpad.net/~mysql/mysql-server/5.1/diff/3560.8.4 Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f8f3306.9020...@etorok.net
Re: Proposal for update of http://debian.org/CD/faq/#verify
On 01/26/2011 02:04 AM, Naja Melan wrote: *3. Could a malicious attacker that feeds me an altered iso image not also feed me an altered SHA256SUMS file? Yes, they could! Http is very easy to intercept. This is where SHA256SUMS.sign comes in. This file is the pgp signature of the ***SHA256SUMS file. It is signed with the Debian CD signing key which can be obtained from hkp://keyring.debian.org/ http://keyring.debian.org/.* The transport from the keyserver is *not *secured, and the only way to verify you have not been fed a bogus key is through the web of trust https://secure.wikimedia.org/wikipedia/en/wiki/Web_of_trust if you are connected to enough people to make a path to the Debian CD signing key. * *What should I do if I am not connected through the web of trust? There is no easy answer to this.* What if you already have an older Debian install, or an older Debian CD (that you already verified/trust by other means)? There should be a chain of trust from the signing keys used on the old CDs all the way to the signing key used on the new CD, right? Is there an easy way to check the signing key, given an older Debian CD? (besides booting from it, and checking the new key with gpg)? Best regards, --Edwinb -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d406b34.7060...@gmail.com
Re: non-executable stack (via PT_GNU_STACK) not being enforced
On Sun, 10 Oct 2010 14:05:52 -0400 Brchk05 brch...@aim.com wrote: It's a 32-bit kernel and probably does not have PAE support enabled so I think the mystery has been solved. Thanks to everyone for your help. Try linux-image-2.6-686-bigmem, it probably has PAE enabled. Best regards, -_Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101010212530.20533...@deb0
Re: [Vg. #202271] [SECURITY] [DSA 2038-2] New pidgin packages fix regression
On Wed, 14 Jul 2010 08:14:01 +0200 Anish Pulimuttath Asokan supp...@mitacs.com wrote: not important. we can safely ignore it. Then ignore it, but don't send a reply to each and every security announcement to debian-security@lists.debian.org On Wed, 14 Jul 2010 07:37:14 +0200 Anish Pulimuttath Asokan supp...@mitacs.com wrote: Not important. We are not using ZNC. Why reply to the announcement then? --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/rt-3.8.0-16019-1279091878-942.202271-...@mitacs
Re: [volatile] Updated clamav-related packages available for testing
On 2010-04-15 22:49, Adam D. Barratt wrote: On Thu, 2010-04-15 at 20:58 +0200, Kurt Roeckx wrote: On Wed, Apr 14, 2010 at 10:35:41PM +0100, Adam D. Barratt wrote: The clamav project have announced that they will be publishing a specially formed virus signature which disables older versions of the software, including the version in lenny. If you have not yet migrated to using the volatile packages, now would be a good time to do so. :-) What does this mean exactly? Will it now tell that everything is not a virus, even for things that it used to be able to detect? That doesn't seem particularly easy to determine from the announcements provided by upstream, unless I'm looking in the wrong places; the wording I used was very much based on their EOL announcement. Run freshclam and you'll see. clamd 0.94.2 says: LibClamAV Warning: *** LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq *** LibClamAV Warning: *** LibClamAV Error: cli_hex2str(): Malformed hexstring: This ClamAV version has reached End of Life! Please upgrade to version 0.95 or later. For more information see www.clamav.net/eol-clamav-094 and www.clamav.net/download (length: 169) LibClamAV Error: Problem parsing database at line 742 Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bc77142.5030...@gmail.com
Re: CVE-2004-0230 RST DoS vulnerability in Lenny?
On 2010-02-11 22:55, JW wrote: Recently we've had a scanning vendor tell us our Debian Lenny 5.0.3 is vulnerable to CVE-2004-0230: TCP/IP Sequence Prediction Blind Reset Spoofing DoS It may be possible to send spoofed RST packets to the remote system. . . . vulnerable to a sequence number approximation bug, which may allow an attacker to send spoofed RST packets to the remote host and close established connections . . . When I tried to look up info about it - one pages lists Linux as vulnerable (with no additional information) and I am not able to find anything about Debian's status or relationship to it except possibly for http://www.mail-archive.com/secure-testing-comm...@lists.alioth.debian.org/msg01390.html which possibly indicates it's fixed, or someone tried to fix it in 2005. That says: CVE-2004-0230 (TCP, when using a large Window Size, makes it easier for remote ...) NOT-FOR-US: famous TCP RST bug See here for more information, it seems it is something to care about only if you do BGP routing: http://lwn.net/Articles/81560/ See also redhat's statement on this: http://www.redhat.com/security/data/cve/CVE-2004-0230.html Does anyone know anything about this? I'm needing some kind of fix or work-around so I can satisfy the scan vendor. Not-a-bug? Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: rootkit not found by rkhunter
On 2009-10-04 19:10, Noah Meyerhans wrote:
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.
Why is not EXTRAVERSION updated during the kernel package build?
Best regards,
--Edwin
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Linux infected ?
Rodrigo Hashimoto wrote: Hi, I received a file via e-mail and tried to open it, then the iceweasel did nothing. I tried again and I realized the iceweasel was trying to user the wine to open a file .com. Then I run the command file and I realized this is king of a virus to Windows and not Linux. This is a security risk to my debian lenny ? It may attempt to infect the other programs you installed with wine. It shouldn't be able to modify any of your Linux program that you have installed, since only root can do that (you're not running iceweasel/icedove as root, are you?). Try scanning your .wine directory like this: $ clamscan -ri ~/.wine Best regards, --Edwin -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 1680-1] New clamav packages fix potential code execution
On 2008-12-05 20:15, Dominic Hargreaves wrote: On Thu, Dec 04, 2008 at 09:26:17AM +0100, Florian Weimer wrote: Moritz Jodeit discovered that ClamAV, an anti-virus solution, suffers from an off-by-one-error in its VBA project file processing, leading to a heap-based buffer overflow and potentially arbitrary code execution (CVE-2008-5050). Ilja van Sprundel discovered that ClamAV contains a denial of service condition in its JPEG file processing because it does not limit the recursion depth when processing JPEG thumbnails (CVE-2008-5314). For the stable distribution (etch), these problems have been fixed in version 0.90.1dfsg-4etch16. For the unstable distribution (sid), these problems have been fixed in version 0.94.dfsg.2-1. This looks like quite a serious bug (remote arbitrary code execution). Are there any plans for an update to volatile? A zero is written past end of allocated heap memory, and not an arbitrary/attacker-controlled character. I don't see how you can execute arbitrary code with that. Best regards, --Edwin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recent problem with security repository?
Benedikt Hallinger wrote: Good morning, at one of my boxes i run apticron. Since the last night, i am unable to use aptitude (also apt doesn't work) anymore. My sources-list contains: deb http://security.debian.org etch/updates main And what else does it contain? This happens if i do an aptitude update: Hit http://security.debian.org etch/updates/main Packages Fetched 4B in 0s (5B/s) Reading package lists... Error! E: Dynamic MMap ran out of room E: Error occurred while processing libcairo-directfb2 (NewVersion1) E: Problem with MergeList /var/lib/apt/lists/security.debian.org_dists_etch_updates_main_binary-amd64_Packages E: The package lists or status file could not be parsed or opened. E: Couldn't rebuild package cache The errors do also occur if i run any other apt/aptitude command. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337831 Strangely, on my other box this doesn't happen. Is something corrupt on the machine? If i manually remove the package cache and do aptitude update, the problem is reproducable. Any help is greatly appreciated. Raise APT::Cache-Limit as the bugreport suggests , or use fewer entries in sources.list. Best regards, --Edwin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is oldstable security support duration something to be proud of?
Filipus Klutiero wrote: free distros if you want. Let's take these 3 which are not too far from Debian's quality: RHEL and derivatives: 7 years Rather than using a 7 year old product with security updates, you can use a newer stable release [*]. For Debian when security support ends, there is a new stable release available for at least a year. Upgrading from oldstable to stable is supported. During that year you had plenty of time to test upgrading from oldstable to the new stable release. IMHO if there is a new stable release available for a reasonable time (1 year is more than reasonable), then having longer security support for an old release doesn't add to a distribution's quality. The Debian security team should definitely be proud for doing a good job! [*] Also the old product can have vulnerabilities that do not affect the latest stable, (for example portions of code got rewritten to be more robust), and thus the old product won't get security updates. But are you safer using the old product? No, because if somebody writes an exploit for it (the old product) you are not protected; however if you are using a newer stable release, you wouldn't be affected by it at all. There are other factors to consider, like length of security support from upstream for old releases. Debian is somewhat better than openSUSE, equal or slightly worst than Ubuntu and definitely worst than RHEL and derivatives. So on average, Debian is somewhat worst than its main alternatives in this aspect. IMO one shouldn't show off unless being at least a bit above average. IHMO you can't judge a distribution's quality based on the length of security support alone. Also consider that having equal amounts of resources having less stable releases to support means you get better support. [during 7 years you need to support multiple versions] Best regards, --Edwin [IANADD] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why not have firewall rules by default?
Henrique de Moraes Holschuh wrote: On Wed, 23 Jan 2008, Rolf Kutz wrote: On 23/01/08 08:29 -0700, Michael Loftis wrote: It's better to leave the service disabled, or even better, completely uninstalled from a security standpoint, and from a DoS standpoint as well. The Linux kernel isn't very efficient at processing firewall rules. Newer I thought it was very efficient in doing so. YMMV. Quite the contrary. It is *dog* *slow* for non-trivial firewalls. You have to use a number of tricks to optimize the rule walk (many tables, hashing, etc), and anything that reduces the number of rules (like IPSet) is a major performance bonus. Are you referring to 2.4 or 2.6 kernel? If it is 2.6, I suggest you to contact the netfilter mailing list [1], and show them your firewall rules, with speed measurements on real workload. I'm sure they will try to optimize the kernel, if it turns out to be a bottleneck in the kernel. [1] http://vger.kernel.org/vger-lists.html#netfilter Best regards, --Edwin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ping22: can not kill this process
Mike Wang wrote: Hi Recently one of my web server was invaded by something called ping22. it obviously exploited some perl cgi or php holes on this apache2 server. But I do not how it is get exploited. (1) tried to kill -9 it, it is respawn again automatically. respawn by whom? Try to use pstree to find out. Best regards, --Edwin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
