Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. > > Yes, this will make the build unreproducible, but no better solution > currently exists. There are some plans, but no-one is working on them. > If a suitable replacement shows up, we can always switch to that > solution. Builds for the architectures involved are already unreproducible due to inconsistent generation of BTF in both the kernel and modules. Additionally, my "plan" would also get rid of signing modules with the Secure Boot CA, so I'm not going to object to this. [...] > ## Image packages contains more version info > > By renaming the kernel packages we try to make several kernels > installable at the same time. In contrast to rpm, where you can have > the same package installed multiple times in different versions, dpkg > only supports a single one at the same time. So the co-installable > versions needs to have different package names. > > The packages will include the full upstream version. There exists the > exception of devel builds and uploads to experimental, wich will contain > even less of the version, to avoid new names in that cases. > > Example: linux-image-6.5.3-cloud-arm64 > > There are some drawbacks. > > The same upstream version in testing and backports will have the same > package name. This is not OK, because they will be incompatible on architectures supporting SB (and sometimes incompatible on others due to compiler differences or required config changes). If someone upgrades from stable + backports to testing, and has OOT modules: - With DKMS, will a rebuild be triggered if the linux-image package name doesn't change? - With module-assistant, the new linux-image package will satisfy dependencies of the old modules even though they are incompatible. > Multiple uploads of the same upstream version will have > the same package name, but those rarely happens. Those happen fairly often for urgent security updates. > Those packages will > not be compatible and a reboot is necessary to be able to load modules > again. > > It will not longer be possible to reliably derive the package name from > kernel release (see above), as both values are not really related > anymore. Given all the drawbacks, I don't see the benefit of decoupling package names from release strings. In the same way that shared library packages must be renamed for every backward-incompatible ABI changes, I believe we should keep doing this for linux-image packages. > ## Header and tool packages will not longer contain version > > The headers packages will not longer include the version. It won't be > reliably possible to derive the package name anyway from the running > kernel. > > This means that only headers of one single version can be available on > the system at one time. This might be a bit inconvinient for dkms, as > it can't longer build modules for multiple versions. > > But we too often have the problem that image and headers go out of sync > and then you can't find the correct ones anyway. > > Example: linux-headers-cloud-arm64 This is all downside with no justification given. Please explain what the benefit is. > ## Installer packages will not longer contain too much version > > The installer can only ever handle one version of kernel. Also it got > an internal mechanism to detect which packages belong together > (the Kernel-Version control entry). So we have no need to rename them > and force a matching change in d-i itself just because a new kernel > exists. So it will not longer contain the full version in the package > names if not needed. [...] In the installer, netboot images break every time the kernel ABI is bumped. I think there's a specific check and error message for this, but I'm not exactly sure. It should be verified that this detection will work the way you expect, so that the error message doesn't change and create a support burden for the installer team. Currently kernel-wedge generates the udeb package names and would need to add an option to leave out the version part of the names. I'm happy to work on that once we have an agreement for what to do. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA 5173-1] linux security update
On Mon, 2022-07-04 at 22:17 +0200, Kurt Roeckx wrote: > On Sun, Jul 03, 2022 at 03:49:12PM +0000, Ben Hutchings wrote: > > > > For the oldstable distribution (buster), these problems have been > > fixed in version 4.19.249-2. > > It seems that linux-image-amd64 does not depend on > linux-image-4.19.0-21-amd64 but still on linux-image-4.19.0-20-amd64, > so the fixed version does not get installed on an apt upgrade. Maybe it wasn't released at the same time, but I uploaded linux-latest on 30th June and the binaries are certainly available now. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
[SECURITY] [DSA 5173-1] linux security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-5173-1 secur...@debian.org https://www.debian.org/security/Ben Hutchings July 03, 2022 https://www.debian.org/security/faq - - Package: linux CVE ID : CVE-2021-4197 CVE-2022-0494 CVE-2022-0812 CVE-2022-0854 CVE-2022-1011 CVE-2022-1012 CVE-2022-1016 CVE-2022-1048 CVE-2022-1184 CVE-2022-1195 CVE-2022-1198 CVE-2022-1199 CVE-2022-1204 CVE-2022-1205 CVE-2022-1353 CVE-2022-1419 CVE-2022-1516 CVE-2022-1652 CVE-2022-1729 CVE-2022-1734 CVE-2022-1974 CVE-2022-1975 CVE-2022-2153 CVE-2022-21123 CVE-2022-21125 CVE-2022-21166 CVE-2022-23960 CVE-2022-26490 CVE-2022-27666 CVE-2022-28356 CVE-2022-28388 CVE-2022-28389 CVE-2022-28390 CVE-2022-29581 CVE-2022-30594 CVE-2022-32250 CVE-2022-32296 CVE-2022-33981 Debian Bug : 922204 1006346 1013299 Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks. CVE-2021-4197 Eric Biederman reported that incorrect permission checks in the cgroup process migration implementation can allow a local attacker to escalate privileges. CVE-2022-0494 The scsi_ioctl() was susceptible to an information leak only exploitable by users with CAP_SYS_ADMIN or CAP_SYS_RAWIO capabilities. CVE-2022-0812 It was discovered that the RDMA transport for NFS (xprtrdma) miscalculated the size of message headers, which could lead to a leak of sensitive information between NFS servers and clients. CVE-2022-0854 Ali Haider discovered a potential information leak in the DMA subsystem. On systems where the swiotlb feature is needed, this might allow a local user to read sensitive information. CVE-2022-1011 Jann Horn discovered a flaw in the FUSE (Filesystem in User-Space) implementation. A local user permitted to mount FUSE filesystems could exploit this to cause a use-after-free and read sensitive information. CVE-2022-1012, CVE-2022-32296 Moshe Kol, Amit Klein, and Yossi Gilad discovered a weakness in randomisation of TCP source port selection. CVE-2022-1016 David Bouman discovered a flaw in the netfilter subsystem where the nft_do_chain function did not initialize register data that nf_tables expressions can read from and write to. A local attacker can take advantage of this to read sensitive information. CVE-2022-1048 Hu Jiahui discovered a race condition in the sound subsystem that can result in a use-after-free. A local user permitted to access a PCM sound device can take advantage of this flaw to crash the system or potentially for privilege escalation. CVE-2022-1184 A flaw was discovered in the ext4 filesystem driver which can lead to a use-after-free. A local user permitted to mount arbitrary filesystems could exploit this to cause a denial of service (crash or memory corruption) or possibly for privilege escalation. CVE-2022-1195 Lin Ma discovered race conditions in the 6pack and mkiss hamradio drivers, which could lead to a use-after-free. A local user could exploit these to cause a denial of service (memory corruption or crash) or possibly for privilege escalation. CVE-2022-1198 Duoming Zhou discovered a race condition in the 6pack hamradio driver, which could lead to a use-after-free. A local user could exploit this to cause a denial of service (memory corruption or crash) or possibly for privilege escalation. CVE-2022-1199, CVE-2022-1204, CVE-2022-1205 Duoming Zhou discovered race conditions in the AX.25 hamradio protocol, which could lead to a use-after-free or null pointer dereference. A local user could exploit this to cause a denial of service (memory corruption or crash) or possibly for privilege escalation. CVE-2022-1353 The TCS Robot tool found an information leak in the PF_KEY subsystem. A local user can receive a netlink message when an IPsec daemon registers with the kernel, and this could include sensitive information. CVE-2022-1419 Minh Yuan discovered a race condition in the vgem virtual GPU driver that can lead to a use-after-free. A local user permitted to access the GPU device can exploit this to cause a denial of service (crash or memory corruption) or possibly for privilege escalation. CVE-2022-1516 A NULL pointer dereference flaw in the implementation of the X.25 set of standardized network protocols, which can result in denial of service. This driver is not enabled in Debian's official
Re: [SECURITY] [DSA 4187-1] linux security update
On Thu, 2018-05-03 at 00:06 +0100, Dominic Hargreaves wrote: > On Tue, May 01, 2018 at 05:12:02PM +0000, Ben Hutchings wrote: > > - > > Debian Security Advisory DSA-4187-1 secur...@debian.org > > https://www.debian.org/security/ Ben Hutchings > > May 01, 2018 https://www.debian.org/security/faq > > - > > > > Package: linux > > CVE ID : CVE-2015-9016 CVE-2017-0861 CVE-2017-5715 CVE-2017-5753 > > CVE-2017-13166 CVE-2017-13220 CVE-2017-16526 CVE-2017-16911 > > CVE-2017-16912 CVE-2017-16913 CVE-2017-16914 CVE-2017-18017 > > CVE-2017-18203 CVE-2017-18216 CVE-2017-18232 CVE-2017-18241 > > CVE-2018-1066 CVE-2018-1068 CVE-2018-1092 CVE-2018-5332 > > CVE-2018-5333 CVE-2018-5750 CVE-2018-5803 CVE-2018-6927 > > CVE-2018-7492 CVE-2018-7566 CVE-2018-7740 CVE-2018-7757 > > CVE-2018-7995 CVE-2018-8781 CVE-2018-8822 CVE-2018-104 > > CVE-2018-1000199 > > > > Several vulnerabilities have been discovered in the Linux kernel that > > may lead to a privilege escalation, denial of service or information > > leaks. > > There are multiple reports on #ganeti that this update breaks networking > in certain circumstances, probably multiple tun/tap device configurations. > No more details or a proper bug report yet as I haven't experienced this > myself, but mentioning in case it saves anyone else breakage.[...] I believe I understand this. Creating a tun/tap device using a name pattern such as "tun%d" (or empty name) will now fail if the number substituted is not 0. There is an upstream fix for this that I failed to spot in time. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams signature.asc Description: This is a digitally signed message part
[SECURITY] [DSA 4187-1] linux security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-4187-1 secur...@debian.org https://www.debian.org/security/Ben Hutchings May 01, 2018 https://www.debian.org/security/faq - - Package: linux CVE ID : CVE-2015-9016 CVE-2017-0861 CVE-2017-5715 CVE-2017-5753 CVE-2017-13166 CVE-2017-13220 CVE-2017-16526 CVE-2017-16911 CVE-2017-16912 CVE-2017-16913 CVE-2017-16914 CVE-2017-18017 CVE-2017-18203 CVE-2017-18216 CVE-2017-18232 CVE-2017-18241 CVE-2018-1066 CVE-2018-1068 CVE-2018-1092 CVE-2018-5332 CVE-2018-5333 CVE-2018-5750 CVE-2018-5803 CVE-2018-6927 CVE-2018-7492 CVE-2018-7566 CVE-2018-7740 CVE-2018-7757 CVE-2018-7995 CVE-2018-8781 CVE-2018-8822 CVE-2018-104 CVE-2018-1000199 Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks. CVE-2015-9016 Ming Lei reported a race condition in the multiqueue block layer (blk-mq). On a system with a driver using blk-mq (mtip32xx, null_blk, or virtio_blk), a local user might be able to use this for denial of service or possibly for privilege escalation. CVE-2017-0861 Robb Glasser reported a potential use-after-free in the ALSA (sound) PCM core. We believe this was not possible in practice. CVE-2017-5715 Multiple researchers have discovered a vulnerability in various processors supporting speculative execution, enabling an attacker controlling an unprivileged process to read memory from arbitrary addresses, including from the kernel and all other processes running on the system. This specific attack has been named Spectre variant 2 (branch target injection) and is mitigated for the x86 architecture (amd64 and i386) by using the "retpoline" compiler feature which allows indirect branches to be isolated from speculative execution. CVE-2017-5753 Multiple researchers have discovered a vulnerability in various processors supporting speculative execution, enabling an attacker controlling an unprivileged process to read memory from arbitrary addresses, including from the kernel and all other processes running on the system. This specific attack has been named Spectre variant 1 (bounds-check bypass) and is mitigated by identifying vulnerable code sections (array bounds checking followed by array access) and replacing the array access with the speculation-safe array_index_nospec() function. More use sites will be added over time. CVE-2017-13166 A bug in the 32-bit compatibility layer of the v4l2 ioctl handling code has been found. Memory protections ensuring user-provided buffers always point to userland memory were disabled, allowing destination addresses to be in kernel space. On a 64-bit kernel a local user with access to a suitable video device can exploit this to overwrite kernel memory, leading to privilege escalation. CVE-2017-13220 Al Viro reported that the Bluetooth HIDP implementation could dereference a pointer before performing the necessary type check. A local user could use this to cause a denial of service. CVE-2017-16526 Andrey Konovalov reported that the UWB subsystem may dereference an invalid pointer in an error case. A local user might be able to use this for denial of service. CVE-2017-16911 Secunia Research reported that the USB/IP vhci_hcd driver exposed kernel heap addresses to local users. This information could aid the exploitation of other vulnerabilities. CVE-2017-16912 Secunia Research reported that the USB/IP stub driver failed to perform a range check on a received packet header field, leading to an out-of-bounds read. A remote user able to connect to the USB/IP server could use this for denial of service. CVE-2017-16913 Secunia Research reported that the USB/IP stub driver failed to perform a range check on a received packet header field, leading to excessive memory allocation. A remote user able to connect to the USB/IP server could use this for denial of service. CVE-2017-16914 Secunia Research reported that the USB/IP stub driver failed to check for an invalid combination of fields in a received packet, leading to a null pointer dereference. A remote user able to connect to the USB/IP server could use this for denial of service. CVE-2017-18017 Denys Fedoryshchenko reported that the netfilter xt_TCPMSS module failed to validate TCP header lengths, potentially leading to a use-after-free. If this module
Re: pulling in other vulnerability databases
On Thu, 2018-01-25 at 10:17 -0500, Antoine Beaupré wrote: [...] > > OS vendors (RH/SUSE) > > Upstream projects (Xen, Linux etc) > > I believe those already follow the CVE process and eventually converge > over doing the right thing. So I am not really concerned about those > people. [...] Linux has a security contact (secur...@kernel.org), but this is only used for reporting bugs and discussing how to fix them; CVE assignments are left to distributions, DWF, etc. Many security fixes don't get discussed there anyway. I would estimate that less than half of security fixes in Linux actually get CVE IDs. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
[SECURITY] [DSA 4073-1] linux security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-4073-1 secur...@debian.org https://www.debian.org/security/Ben Hutchings December 23, 2017 https://www.debian.org/security/faq - - Package: linux CVE ID : CVE-2017-8824 CVE-2017-16538 CVE-2017-16644 CVE-2017-16995 CVE-2017-17448 CVE-2017-17449 CVE-2017-17450 CVE-2017-17558 CVE-2017-17712 CVE-2017-17741 CVE-2017-17805 CVE-2017-17806 CVE-2017-17807 CVE-2017-17862 CVE-2017-17863 CVE-2017-17864 CVE-2017-1000407 CVE-2017-1000410 Several vulnerabilities have been discovered in the Linux kernel that may lead to a privilege escalation, denial of service or information leaks. CVE-2017-8824 Mohamed Ghannam discovered that the DCCP implementation did not correctly manage resources when a socket is disconnected and reconnected, potentially leading to a use-after-free. A local user could use this for denial of service (crash or data corruption) or possibly for privilege escalation. On systems that do not already have the dccp module loaded, this can be mitigated by disabling it: echo >> /etc/modprobe.d/disable-dccp.conf install dccp false CVE-2017-16538 Andrey Konovalov reported that the dvb-usb-lmedm04 media driver did not correctly handle some error conditions during initialisation. A physically present user with a specially designed USB device can use this to cause a denial of service (crash). CVE-2017-16644 Andrey Konovalov reported that the hdpvr media driver did not correctly handle some error conditions during initialisation. A physically present user with a specially designed USB device can use this to cause a denial of service (crash). CVE-2017-16995 Jann Horn discovered that the Extended BPF verifier did not correctly model the behaviour of 32-bit load instructions. A local user can use this for privilege escalation. CVE-2017-17448 Kevin Cernekee discovered that the netfilter subsystem allowed users with the CAP_NET_ADMIN capability in any user namespace, not just the root namespace, to enable and disable connection tracking helpers. This could lead to denial of service, violation of network security policy, or have other impact. CVE-2017-17449 Kevin Cernekee discovered that the netlink subsystem allowed users with the CAP_NET_ADMIN capability in any user namespace to monitor netlink traffic in all net namespaces, not just those owned by that user namespace. This could lead to exposure of sensitive information. CVE-2017-17450 Kevin Cernekee discovered that the xt_osf module allowed users with the CAP_NET_ADMIN capability in any user namespace to modify the global OS fingerprint list. CVE-2017-17558 Andrey Konovalov reported that that USB core did not correctly handle some error conditions during initialisation. A physically present user with a specially designed USB device can use this to cause a denial of service (crash or memory corruption), or possibly for privilege escalation. CVE-2017-17712 Mohamed Ghannam discovered a race condition in the IPv4 raw socket implementation. A local user could use this to obtain sensitive information from the kernel. CVE-2017-17741 Dmitry Vyukov reported that the KVM implementation for x86 would over-read data from memory when emulating an MMIO write if the kvm_mmio tracepoint was enabled. A guest virtual machine might be able to use this to cause a denial of service (crash). CVE-2017-17805 It was discovered that some implementations of the Salsa20 block cipher did not correctly handle zero-length input. A local user could use this to cause a denial of service (crash) or possibly have other security impact. CVE-2017-17806 It was discovered that the HMAC implementation could be used with an underlying hash algorithm that requires a key, which was not intended. A local user could use this to cause a denial of service (crash or memory corruption), or possibly for privilege escalation. CVE-2017-17807 Eric Biggers discovered that the KEYS subsystem lacked a check for write permission when adding keys to a process's default keyring. A local user could use this to cause a denial of service or to obtain sensitive information. CVE-2017-17862 Alexei Starovoitov discovered that the Extended BPF verifier ignored unreachable code, even though it would still be processed by JIT compilers. This could possibly be used by local users for denial of service. It also increases the severity of bugs in determining unreachabl
Re: NSA software in Debian
On Tue, 2014-01-28 at 20:29 +1100, Russell Coker wrote: On Fri, 24 Jan 2014, Marko Randjelovic marko...@eunet.rs wrote: I would also like this. Yesterday I started compiling 3.2.54 with grsec and PaX. A ready debian kernel(-source) with grsec and PaX would be fine. Currently I am distributing my special packages via my own repository - is there any concern when making it public (copyright, etc.)? I managed to do it from official kernel 3.2.51-1. I removed all features/* patches without consideration because there were to many of them (905). Than I had to remove many other patches to resolve conflicts. If patch file f is patched consequently by patches p1, p2, if patch p1 is removed, then p2 may fail. The correct thing to do is just prepare a GRSecurity patch that applies on top of the Debian kernel patches. That will be an unholy mixture not supported by either Debian or GRSecurity. May I remind you of #605090; in particular: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#223 At one time (10+ years ago) I was maintaining patches for GRSecurity and LSM/SELinux and doing this for every new Debian kernel package and new version of GRSecurity and LSM/SELinux. http://packages.debian.org/jessie/linux-patch-grsecurity2 [...] I bet it doesn't apply to 3.2.y any more... no, it doesn't. Bug opened (#736925). Ben. -- Ben Hutchings It is a miracle that curiosity survives formal education. - Albert Einstein signature.asc Description: This is a digitally signed message part
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On Sat, 2013-12-14 at 19:00 -0200, Henrique de Moraes Holschuh wrote: On Sat, 14 Dec 2013, Steven Chamberlain wrote: On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: Yeah, I think Linux went through similar blindness braindamage sometime ago, but blind trust on rdrand has been fixed for a long time now, and it never trusted any of the other HRNGs (or used them for anything at all without a trip through rng-tools userspace until v3.12). I seem to remember that Ted T'so's committed the fix for this only after the release of Linux 3.2, so I assuemd wheezy's kernels might be still affected? I'd need to check it througoutly, but almost all important /dev/random changes in Linux were backported to all stable kernels, and thus eventually migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of other backports). If I understand rightly, in Linux 3.2 RDRAND (or other architectural HWRNG) was used for get_random_int() and get_random_bytes() but not for /dev/random or /dev/urandom. Linux 3.2.27 (and other stable updates) inclued a large set of security improvements for the RNG, primarily addressing lack of entropy at boot (see https://factorable.net). As part of this, an architectural HWRNG will be used as a extra source of entropy for /dev/random and /dev/urandom, but credited as providing only a fraction of a bit of entropy. get_random_bytes() was changed to not use an architectural HWRNG. get_random_int() and get_random_bytes_arch() will use it and it is documented that they are not suitable for cryptographic purposes. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: CVE-2013-2224 RHEL-specific?
On Fri, 2013-07-05 at 10:54 +0100, Steven Chamberlain wrote: Hi, I notice CVE-2013-2224 was marked in the security tracker as affecting only RHEL kernels, but I just wanted to double-check that: The issue was allegedly introduced into RHEL by a backport of a mainline commit, to try to fix CVE-2012-3552: f6d8bd051c391c1c0458a30b2a7abcd939329259 (inet: add RCU protection to inet-opt) But the Debian changelog[0] for 2.6.32-48squeeze3 (aka squeeze2) mentions something similar was done: * inet: add RCU protection to inet-opt (CVE-2012-3552) and the actual same commit was seemingly applied as a patch[1]. [0]: http://anonscm.debian.org/viewvc/kernel/dists/squeeze-security/linux-2.6/debian/changelog?revision=20073view=markup [1]: http://anonscm.debian.org/viewvc/kernel/dists/squeeze-security/linux-2.6/debian/patches/bugfix/all/inet-add-RCU-protection-to-inet-opt.patch?view=markuppathrev=19969 Our backport is different. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Re: [SECURITY] [DSA 2480-1] request-tracker3.8 security update
Hi I also came across this issue applying the fix yesterday. I did resolve it though by doing an apache restart. Ben Dominic Hargreaves wrote: On Fri, May 25, 2012 at 09:29:44AM +0100, Dominic Hargreaves wrote: On Thu, May 24, 2012 at 07:37:03PM +0200, Moritz Muehlenhoff wrote: Several vulnerabilities were discovered in Request Tracker, an issue tracking system: For the stable distribution (squeeze), this problem has been fixed in version 3.8.8-7+squeeze2. This fix introduced a regression for deployments using mod_perl; sending outgoing email is broken. Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674522 for more information. If you are using RT in this mode you may wish to hold off on applying the update until this problem is fixed. There has also been another regression reported which I have not confirmed yet: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674558 -- Ben Whyall -- 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/a22fa9e6c5a22e3a716f8b6eb425f957.squir...@secure.awke.co.uk
Re: Bug#605090: Linux 3.2 in wheezy
On Fri, Feb 03, 2012 at 12:55:59AM +0100, Christoph Anton Mitterer wrote: On Thu, 2012-02-02 at 12:18 +1100, Russell Coker wrote: The current approach of having a kernel patch package seems to work well. Phew... well there are many people running at stable... and for them it does not... as the package seems more or less orphaned. Also,.. configuring something complex like grsec is probably nothing for the end-user who, however, should have also an easy way to benefit from it. There is an easy way to benefit from it. Download and build an official release. I assume 'make deb-pkg' works like in mainline Linux. It removes the need for involvement of the kernel and security teams (presumably security changes to the kernel will usually not require changes to the grsecurity patch) and allows the users to easily build their own kernels. Well, even though it means [much] work for them,... wouldn't that involvement be just the good thing? Having some real experts, looking after everything?! You flatter us. General experience with kernel development does not make someone an expert that is capable of understanding all the implications of rebasing a patch or patch set that modifies many core kernel features. Spender suggested that people who want GRSecurity on Debian would be better off using a .deb he provides and working on user-space hardening. Well IMHO, at best, one should never need to rund anything from outside the Debian archives ;) Wishing it so doesn't make it practically possible. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120203003410.gx12...@decadent.org.uk
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? I don't speak for the whole team, but I don't see that it solves any problem. You would have to Build-Depend on exact versions of linux-source, so that you know your external patches will apply. Then you would have to rebase the patches every time linux-2.6 is updated, making sure (without much help from upstream) that you don't introduce a subtle security problem. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: Bug#605090: Linux 3.2 in wheezy
On Wed, Feb 01, 2012 at 06:41:43PM +0100, Yves-Alexis Perez wrote: On mer., 2012-02-01 at 14:32 +, Ben Hutchings wrote: On Wed, 2012-02-01 at 10:51 +0100, Yves-Alexis Perez wrote: On mer., 2012-02-01 at 10:34 +0100, Wouter Verhelst wrote: On Wed, Feb 01, 2012 at 10:24:40AM +0100, Yves-Alexis Perez wrote: On mar., 2012-01-31 at 11:01 -0500, micah anderson wrote: What is stopping you from creating another package, that provides the kernel with grsecurity patches applied? Don't bother the kernel team with it, and just maintain it yourself in the archive? Its free software afterall. Honestly, having multiple linux source package in the archive doesn't really sound like a good idea. I don't really think the kernel team would appreciate, I'm pretty sure ftpmasters would disagree, and as a member of the security team, It's definitely something I would object. Well, that's what we have the 'linux-source' packages for: to allow other packages to build-depend on them. Hmhm, that might be a good idea indeed. I need to investigate and try that a bit. Ben, what would kernel team think of that? I don't speak for the whole team, but I don't see that it solves any problem. You would have to Build-Depend on exact versions of linux-source, so that you know your external patches will apply. Then you would have to rebase the patches every time linux-2.6 is updated, making sure (without much help from upstream) that you don't introduce a subtle security problem. Well, that's already what I do and intended to do (and that's clear from the beginning of the bug report). Wrt not introducing subtle security problems, what I mostly do is remove the security backports from the grsec patch which are already applied to Debian kernel, so this part is fairly straightforward. Now indeed when doing the job for Squeeze kernel it's a bit less straightforward because of the huge amount of driver backports, but from my own experience, the conflicts are still mostly about changed context lines. But your upstream disagrees on that point. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120201183043.gv12...@decadent.org.uk
Re: Linux 3.2 in wheezy
On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote: (adding few CC:s to keep track on the bug) On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote: On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote: On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote: Featuresets --- The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. However, we do need to consider the total time taken to build binary packages for each architecture. If there are particular container features that should be enabled or backported to provide a useful replacement for OpenVZ or VServer, please let us know. We cannot promise that these will all be enabled but we need to know what is missing. So in the end what are the reasons for not trying the grsecurity featureset? #605090 lacks any reply from the kernel team since quite a while, and especially after answers were provided to question asked. You already know the main reason: Feature-wise, Brad Sprengler and the PaX team still add stuff, like the gcc plugins or hardening features like symbols hiding, fix bugs (for example in RBAC code), while few of them reach mainline. I realise that the mainline Linux developers have sometimes been unreasonably resistant to these changes and I'm not intending to assign blame for this. But practically this means that we have to either carry the featureset indefinitely or disappoint users by removing it in a later release. (See the complaints about removing OpenVZ in wheezy despite 4 years' advance notice of this.) I understand this, and I still see the grsec featureset as a valuable project. Indeed, reducing the diff wrt. upstream in Debian kernel is an important goal (especially considering the time involvement). Now, I still think having a hardened Debian kernel inside the distribution is helpful [...] I agree and I would like to see hardening of *all* our configurations, where the performance cost is not too much. That's going to protect all our users rather than just people who seek out a special paranoid configuration. Ben. -- Ben Hutchings Lowery's Law: If it jams, force it. If it breaks, it needed replacing anyway. signature.asc Description: This is a digitally signed message part
Re: Upcoming stable point release
On Wed, 2012-01-11 at 13:12 +, Adam D. Barratt wrote: Hi, The next point release for squeeze (6.0.4) is scheduled for Saturday January 28th. Stable NEW will be frozen during the preceeding weekend (21st/22nd). As usual, base-files can be uploaded at any point before the freeze. If there is a further kernel update planned for inclusion in the point release, it would be ideal if that could be uploaded over the coming weekend so that we can look at finalising the installer later next week. There are some more important changes pending, including a fix for a regression in 2.6.32-40 (currently in stable-proposed-updates). I can probably make an upload this weekend, but cannot promise that a further upload will not be needed. We need some testing of the isci driver (added in 2.6.32-40) and more generally regression testing. Ben. -- Ben Hutchings When in doubt, use brute force. - Ken Thompson signature.asc Description: This is a digitally signed message part
RE: [SECURITY] [DSA 2222-1] tinyproxy security update
unsubscribe Cordialement, your sincerely, European Parliament Richard BEN ALEYA -Original Message- From: Moritz Muehlenhoff [mailto:j...@debian.org] Sent: 20 April 2011 19:16 To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA -1] tinyproxy security update -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA--1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff April 20, 2011 http://www.debian.org/security/faq - - Package: tinyproxy Vulnerability : incorrect ACL processing Problem type : remote Debian-specific: no CVE ID : CVE-2011-1499 Debian Bug : 621493 Christoph Martin discovered that incorrect ACL processing in TinyProxy, a lightweight, non-caching, optionally anonymizing http proxy could lead to unintended network access rights. The oldstable distribution (lenny) is not affected. For the stable distribution (squeeze), this problem has been fixed in version 1.8.2-1squeeze1. For the unstable distribution (sid), this problem has been fixed in version 1.8.2-2 We recommend that you upgrade your tinyproxy packages. Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: http://www.debian.org/security/ Mailing list: debian-security-annou...@lists.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2vFKcACgkQXm3vHE4uylo6pwCgtCVFoknYhvnWAyE16T8OaQ52 teEAoKjVuBWm802IODvSl8oz5I9Znbf4 =BXfn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420171613.GA3456@pisco.westfalen.local Ce message contient des informations confidentielles à l'intention exclusive du destinataire. Il ne peut être utilisé, divulgué ou copié de quelconque façon que ce soit par une personne autre que le destinataire désigné. Si vous n'êtes pas le destinataire désigné, merci de contacter l'expéditeur et d'effacer ce message. L'expéditeur de ce message n'est pas mandaté à représenter le Parlement européen. Dès lors, ce message ne constitue pas nécessairement le point de vue officiel du Parlement européen, ni un engagement juridique opposable à ce dernier. This message contains confidential information intended solely for the attention of the named addressee. It may not be used, disclosed or copied in any way whatsoever by anyone else than the intended addressee. If you are not the intended addressee, please contact the sender and delete this message. The sender of this message is not authorized to represent the European Parliament and therefore this message does not necessarily reflect the official position of the European Parliament and is not legally binding upon it. -- 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/73eb14e0f1108b47a648477f8fd3ac880443b...@emailbrusv23.ep.parl.union.eu
Re: Fwd: Fwd: question regarding verification of a debian installation iso
Eduardo M KALINOWSKI edua...@kalinowski.com.br writes: How much do you trust your USB drive? It could have a malicious controller that detects when the correct Fedora files are written to it, and replaces with hacked copies. And when you try to verify the copy, it detects this and returns the SHA1 (or any other checksum) of the original files. How would the USB drive tell whether you were reading the file to verify its checksum or to use its contents? -- Ben Pfaff http://benpfaff.org -- 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/877hem0xki@benpfaff.org
Re: [SECURITY] [DSA 1912-1] New camlimages fix arbitrary code execution
For the most part I'm on holidays until 19th of Oct. Cheers Benny If this is an Urgent ticket please submit a repair ticket herehttp://ts.sd57.bc.ca I will be checking my mail during the week! Personal contacts phone me cell at 250-640-3100 Thanks Benn -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: bind9_9.5.1.dfsg.P1-1_i386.changes is NEW
On Mon, 2009-02-09 at 05:17 +, Debian Installer wrote: Changes: bind9 (1:9.5.1.dfsg.P1-1) unstable; urgency=low . * New upstream patch release - supportable version of fix from 9.5.0.dfsg.P2-5.1 - CVE-2009-0025: Closes: #511936 - 2475: Overly agressive cache entry removal. Closes: #511768 - other bug fixes worthy of patch-release inclusion This looks like much too big a change to get into lenny now. You'll probably need to upload just the two critical fixes to t-p-u or testing-security. Ben. signature.asc Description: This is a digitally signed message part
Re: clamav.* package versions (etch)
Martin Zobel-Helas [EMAIL PROTECTED] writes: Is is already escalated, and we are working on that problem getting fixed. clamav will be available in a few minutes. Thanks very much for attending to this. There was quite a lot of discussion in the 'debian-volatile' list, over many weeks, before it got a response from anyone who could do anything about it. Is there somewhere else such issues should be raised? -- \ “It is seldom that liberty of any kind is lost all at | `\once.” —David Hume | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Security Debian Questions
Abdul bijur Vallarkodath [EMAIL PROTECTED] writes: Please do not mis interpret this, but I think you guys are posting on the wrong mailing list. Please take you doubts to #debian or some debian help mailing list. I think you are confusing debian-security with debian-security-announce. The former is for Discussion about security issues, including cryptographic issues, that are of interest to all parts of the Debian community. The latter is where The security team informs the users about security problems by posting security advisories about Debian packages on this list. -- Ben Pfaff http://benpfaff.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy change is needed to keep debian secure
Matt Zimmerman wrote: I guess you aren't reading my mail, then. He may well be. Which browser are you using? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
antgel wrote: 2) Mozilla security patches are not easy to find and isolate. Ben has disputed this, saying that we should be able to extract all necessary patches. Public ones from http://www.mozilla.org/projects/security/known-vulnerabilities.html then bugzilla, and embargoed ones via mdz. Note that I do *not* recommend that approach. I cannot garantee that all security fixes are listed there. Even more so for pro-active security changes which will prevent exploits in the future. (I'm not saying that this *does* happen, I just don't know. Here, communication between the groups would be useful, if nothing else to establish garantees.) Also, this is far more work than just taking an existing branch and ship that. 3) Backporting the patches, once isolated, is a ballache. (Is it that security patches are applied to aviary as well as trunk, and that the problem, more specifically, is that aviary itself is too far ahead of Debian, or that the patches are only applied to trunk?) I'd like to hear a comment from Ben about this. Given that the aviary branch (1.0.x) is maintained by mozilla.org, it does have all the critical security fixes. As I said, I don't know what the problems with backporting are. I mean, right now, you are shipping FF 1.0.4 with sarge. If the 1.0.5/6 patches don't apply to *that*, then I don't know either... Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Matt Zimmerman wrote: Ben has now explained that this is in fact not sufficient. No, I have not. Please read again what I wrote. There is clearly a communication gap. And it's not on my end. You still haven't answered my very specific questions about your problems and what you want. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Importance of browser security (was: On Mozilla-* updates)
Stefano Salvi wrote: I prefer to have no X on the server and administer it from command line or Web interfaces (command line is better). Let's say 1. You use Mozilla from sarge 2. Somebody cracks you through known holes in that old Mozilla, either a mass exploit or an enemy of you specifically targetting you. Which is probably the easiest way to attack you, through all firewalls. So much for browser/email security. 3. He controls your desktop 4. He downloads all your local mail and photos/images, including your confidental company mail, private mail and nude photos of your girlfriend. He posts it on the Internet, your company's billboard, and your supermarket's billboard. 5. He also installs a keyboard sniffer and downloads your private SSH keys. 6. He logs into all servers and other computers that you have access to. Including those desktops of your friends, which you remote administrate or use the password that they use for your server. And the attacker goes on from there. So much for desktop/server security. 7. One of your friends did things which are strictly legal, but your boss didn't like it at all, and fired him. Another one happened to be a dissident and gets in jail or maybe shot. So much for efficiency (this has nothing to do with efficiency). 8. Because all this costs some time, the attacker needs to live, too. He drafts your bank accounts and those of your friends as a fair compensation. The Half Life 2 source code got indeed stolen via desktop compromitation, too. But all that is insignificant in comparison to your dead friend. That's what's at stake here. I don't care, if a Mozilla security update breaks some badly written extensions. And if it breaks Galeon's print function, so be it, you can still use Mozilla in this rare case. But there's *no* recovery from a bad breakin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Matt Zimmerman wrote: I'm guessing that you're not going to volunteer on the manpower side Actually, he did, in the previous posting. Which is admirable, because this is a dauntingly huge task (and he seems semi-aware of it) - in the area of a few hours *per week*, on average. mozilla.org (and before it Netscape) has a full-time staff position just for security (he also does security features, though). You're welcome to attempt to convince the Mozilla project to change the way that they work for the benefit of distribution security teams. I don't even know what exactly you do want the Mozilla project to change. You are officially part of the Mozilla security group since some time, so you are the right person to discuss a collaboration, and execute on it. Note that a discussion involves more than 1-2 emails with statements and requests. BTW: Where are you located physically? Maybe you can meet with mozilla.orgians in person. I think you'll like Daniel Veditz in particular. And Mozilla Foundation needs more of the SPI spirit than the OSAF spirit anyways. I hope you can understand, though, that the Mozilla project can't maintain whatever version you pick for Debian stable, for *3 years*. 1.7.x already lives since almost a year. But, as I said, that's not the problem right now. At the moment, I am still waiting for an answer to the question at the end of my first posting, which Alex repeated: What's preventing you from shipping Moz 1.7.11 and FF 1.0.6 right now? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Matt Zimmerman wrote: To organize their development processes such that patches can be backported with a reasonable amount of effort. I wrote a response, but deleted it, because I simply don't understand what you mean. Please be concrete, very very concrete. I'm in Los Angeles, California, US. If you happen to be in the SF Bay Area sometime, maybe schedule a meeting with Dan. I guess he'd welcome you. Can Mozilla 1.7.11 even be *built* on woody huh? Try it? Or are you expecting me to? And I thought we were talking about sarge. All hope is lost for woody. My question remains unanswered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Thomas Bushnell BSG wrote: It would be very nice if Mozilla would publish to distributions like ours a description of the security problem, and then a separate patch for that specific problem. 1. You to be going to http://www.mozilla.org/projects/security/known-vulnerabilities.html 2. You to be following links to bugzilla entries 3. You to be downloading patch there or better yet search for CVS checkin, which has that bug number in commit log. This is only possible after a release, like right now, i.e. when it's already too late. Distributions like yours, in your case Matt Zimmerman, have access to the resources before that, including bug report details under embargo. It does involve watching the list to see when releases are upcoming and why. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Adeodato Simó wrote: Publish to distributions is effectively the same as making it completely public, so they won't. Wrong. http://www.mozilla.org/projects/security/security-bugs-policy.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On Mozilla-* updates
Hi Martin, thanks for raising this publically. Sorry, if I sound provocive here, but this discussion has a history for me. As I said since several years, the only practical way for Debian to stay up-to-date with Mozilla security updates is to stay current with the latest stable release. For Mozilla SeaMonkey, this means you shipped Mozilla 1.7.6 or whatever was current with Sarge and by now already distribute Mozilla 1.7.11 debs on security.debian.org. Moz 1.7.11 was in cvs since a few days, so enough time to prepare (a few days from patch to end-user is all you get in the security world, and it's doable). It implies that you keep a close eye on what's happening at mozilla.org - if you see the announcement at www.mozilla.org, it's already too late. To faciliate cooperation, I have invited the Debian security people to the Mozilla security team long ago, with no result. I personally maintain 1 or 2 browsers intended for the mass-market on all platforms based on Mozilla 1.7, and the source code changes in the releases were indeed very small, and close to (or at) the minimum possible to fix the security holes. Updates were surprisingly painless. In one case (1.7.7), they did break some functionality, but that was inherent to the security update, because the API (a certain, obscure way to use JavaScript in combination with the DOM) was insecure and I don't think ever intended. As was visible on blogs, the mozilla security was very much trying to find a solution that wouldn't break things. That said, I had no problems at all with our code (although I expected lots). What's more important, everything that *did* break most likely had security hole itself, so arguably *should* break and not be used anymore. So, basically, you can't *always* keep things running as they were and still be secure. What comes to me, the tradeoff is clear: An insecure system is completely unacceptable, and not usable *at all*. So given the choice of some extensions breaking and having gapping security holes, there's IMHO only one choice. What I'm getting at is that you *cannot* maintain your stance of we'll never break or change anything noticable in a stable release for 3 years. If a user wants that, he should cut all network connections and never update. I'm speaking mainly about SeaMonkey, I can't speak about Firefox and Thunderbird, esp. once they hit 1.5. What's hurting you in this case is the ultra-long release cycle of Debian stable. The problem you are *then* facing with backporting security fixes is the same that the mozilla security team would face - very often, it's unjustifiably time-consuming. As far as I know, caillon from and for Redhat (also a Mozilla contributor) is doing that, or at least used to, with Mozilla 1.6. Maybe talk to him? But be prepared: this means real work. But that's not the problem right now. What's wrong with just shipping Firefox and Thunderbird 1.0.6? Frankly, that's what they are meant for. The patches *are* backported from the trunk to 1.0.x for you. And using a different version number only confuses users (who check their vulnerability) and extensions. Concretely, I don't understand what you base your introduction on: it seems that less than two months after the release of sarge it is not possible to support Mozilla, Thunderbird, Firefox ... packages anymore. (in terms of fixing security related problems) What hard reasons are there that prevent you from shipping Firefox 1.0.6 and Mozilla 1.7.11 right now? In the end, though, you have to drop the idea of keeping the everything as-is, no user-noticable changes, for 3 years. You have to lose your current ideas and put security first. (I'm not including freedom etc. here :-) .) I am more than willing to help establish cooperation between Debian and mozilla.org, if there's interest. -- Ben Bucksch If replying privately, please remove .news. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: safety of encrypted filesystems
martin f krafft [EMAIL PROTECTED] writes: However, doesn't CBC or EBC make sure that every block is chained to its predecessor, making even the very last block of a file dependent on the bits of the very first block? Yes and no. If you change the first block in a set of CBC-chained blocks, the last block will change. But to recover the contents of the last block, you only need the last block and the preceding block (and the key). -- I was born lazy. I am no lazier now than I was forty years ago, but that is because I reached the limit forty years ago. You can't go beyond possibility. --Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Procmail recipe for Nitwit unsubscribers who can't read DU sigs.
I've been adding unsubscribe requests and out-of-the-office-nitwit replies to my spam folder, and then training Ye Olde Classifier Of Choyce upon them. Works reasonably well... -- Ben Pearre http://hebb.mit.edu/~ben PGP: CFDA6CDA Don't let Bush read your email! http://www.gnupg.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm (resolved)
Thank you guys so much. It's resolved. The problem was indeed that my default route was via the external IP of my firewall so that it tried to resolve all 134.102.0.0/16 IPs to mac addresses. Raising the arp cache to 2^16 worked as a hot fix. In my defense: When I started working here I did inquire about the gateway to use and I was told I don't need one. I thought that odd back then but didn't realize the implications of this. And it did work for quite a while. Until now that is. Now I've got a proper gateway entry that's outside of my net in a neighbouring /24 subnet and I reduced the arp cache size to 1024 again. And even though I can see 5 infected machine blasting through the network right now everything works fine. Cheers, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
Kurt Roeckx wrote: On Sat, Oct 16, 2004 at 01:39:29PM +0200, Benjamin Goedeke wrote: My net has netmask /24 and the firewall is connected to an upstream router which sits in 134.102.0.0/16. The other gateway sits between my site and two /24 nets but this gateway doesn't seem to be affected. So the gateway with the problem is the only one with a connection to the outside world and they other is just to 2 other internal nets? That's right. The net looks something like this: (excuse my pittyful ascii art skills) Internet Internet | | | the overflowing firewall | | | (bridge) | | | | other lansfirewallmy lan I could use the other lans as a gateway but I usually don't. The only reason it should do ARP is in case it wants to resolv an address which he thinks is directly connected. Which should mean all your internal IP addresses (or atleast those he tried to send something to) your gateway. Hmm. That gives me an idea: Destination Gateway Flags Metric Ref Use Iface 134.102.0.0/16 0.0.0.0 UG 0 0 0 eth1 With such a routing entry the firewall will try and resolve mac addresses when the worm is scanning 134.102.xxx.0 subnets, right? I off to the site to do some experimenting. Thanks, a lot so far. I'll post my findings. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
arp table overflow due to windows worm
Hi list This might be a bit offtopic since there's nothing debian specific about the problem I'm having. If you feel this has no place on this list please point me to a more appropriate list for this question. Starting last week I noticed random network outages on the lan I'm administering. There are 5 debian servers for some 100 windows workstations. The network topology is pretty straight-forward with two gateways to the internet and an affiliated site respectively. Now what happens is this: There's a worm or virus on some of the windows machines that uses tcp port 135 to distribute itself. Infected machines systematically scan neighbouring networks at a rate of a few hundred connection attempts/s for machines listening on port 135. Oddly enough the local scanners (Norton Antivirus) don't find anything. But this mail is not about what to do with the windows machines but rather what to do on the firewall. Obviously port 135 is closed in both directions. However, I get the message Neighbour table overflow on the firewall (debian stable w/ kernel 2.4.27) and the entire network comes to a standstill. The cpu load isn't even close to a worrying level so I guess there are plenty of resources left and still I can't make any network connection through the firewall when there's an infected machine plugged in to the network. The arp cache overflow happens even though I just drop packets in the iptables FORWARD chain. So I set up a transparent bridge between the firewall and the lan and tried filtering ethernet frames using ebtables from the infected machines. This did work and the arp cache overflow on the firewall no longer happened but still the network was pretty much useless and connections to any server outside of the lan are extremely slow and unreliable. Should it really be possible for a single infected windows machine to dos a linux firewall? Please tell me it's not true and there's just something I'm overlooking. I'm at my wits end here and don't even know what to try next. So any pointers are much appreciated. Thanks, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#257165: udev: input device permissions
Actually, re-reading the definitions in reportbug, this seems to be *critical*. Why doesn't anyone DO anything about this? NMU? Something??? On Thu, Jul 01, 2004 at 10:28:04AM -0700, Itay Ben-Yaacov wrote: Package: udev Version: 0.026-1 Severity: normal Tags: security Permissions of /dev/input/* should be 600 or 640, but certainly not 644! Anybody logged on could read my password directly from the event# device associated with the keyboard. Eek! This is severe. -- - mdz ___ALL-NEW Yahoo! Messenger - so many all-new ways to express yourself http://uk.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#257165: udev: input device permissions
It has been broken for weeks and somebody only noticed a couple of days ago, if you can't update the config file by yourself I'm sure you can wait for a few days while I work on other issues. It was repaired on my box before I reported it, of course. Given that it's a single user machine, it is not that important to me anyways. I have no idea for how long it has been broken, but it's definitely been around long enough to make its way into sarge. So there are more machines out there which are potentially affected. Now, people using sid accept the potential consequences, but the consequences for sarge should be somewhat lesser, and in any case I innocently thought such a security hole could be repaired more hastily. Then again, it no longer concerns me. Cheers, Itay ___ALL-NEW Yahoo! Messenger - so many all-new ways to express yourself http://uk.messenger.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
On Monday 28 October 2002 11:59 pm, Jean Christophe ANDRÉ wrote: Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
On Tuesday 29 October 2002 01:02 am, Jean Christophe ANDRÉ wrote: Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. you're missing the point. running a portmap daemon is the only vulnerability that the 111 port scans are attempting to exploit. that attempted exploit is part of the weather of being hooked up, in the same way that 25 is attempted to be used as a mail relay. there are--to the best of my knowledge--no internal apps or daemons that will cause the fashion of log alarm that the op is concerned to address. you're assuming that internal apps attempt external connections. for that to be a possibility, you'd have to have a mighty weird local setup. if you, or anybody, can give me a real example to justify your hypothesis, please do. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: port 16001 and 111
On Monday 28 October 2002 11:59 pm, Jean Christophe ANDRÉ wrote: Tom Cook écrivait : What the What's wrong with 'lsof -i :111' and 'lsof -i :16001'? Nothing wrong with it! :) It tells you precisely what's attempting to connect... Yes, except in his case there is no connection since there is no installed daemon on this port, only some connection attempts he is trying to track. So my solution is just to provide a mini-daemon allowing connecting and so tracking. Use netstat or lsof in /root/spy.sh as you want. I just use to use netstat so I gave an example with netstat, but you can use lsof instead off course! :) Cheers, J.C. way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. ben
Re: port 16001 and 111
On Tuesday 29 October 2002 01:02 am, Jean Christophe ANDRÉ wrote: Hi, ben écrivait : way overkill. 16001 isn't being scanned and 111 is the most common target after 25. you're suggesting that the guy turn his server into a honeypot--to what end? disable portmap and nothing can get at 111. there's a difference between simply securing a box and assuming a role as cyber-detective. the former solves the problem, the latter has no end. Please read the full thread before posting (or even only the first post). He actually *is* asking for tracking the *internal* process trying to connect *localy* to its port 111. He knows about such attempts because he had filtered them. But he can't guess which process attempt to connect to it. And he just *want* to know. Tracking connection attempts *is* part of security, since it allow you to know how things work, and better tune it once you understand it. you're missing the point. running a portmap daemon is the only vulnerability that the 111 port scans are attempting to exploit. that attempted exploit is part of the weather of being hooked up, in the same way that 25 is attempted to be used as a mail relay. there are--to the best of my knowledge--no internal apps or daemons that will cause the fashion of log alarm that the op is concerned to address. you're assuming that internal apps attempt external connections. for that to be a possibility, you'd have to have a mighty weird local setup. if you, or anybody, can give me a real example to justify your hypothesis, please do. ben
Re: Access on Port 0
Wade Richards [EMAIL PROTECTED] writes: Notice the PROTO=UDP part of the message. It means that this is a UDP packet, not a TCP packet. UDP is not a socket-based protocol, so the port number is meaningless for UDP packets. This statement is nonsense. Both TCP and UDP have 16-bit port numbers and both use the sockets API. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Access on Port 0
Wade Richards [EMAIL PROTECTED] writes: Notice the PROTO=UDP part of the message. It means that this is a UDP packet, not a TCP packet. UDP is not a socket-based protocol, so the port number is meaningless for UDP packets. This statement is nonsense. Both TCP and UDP have 16-bit port numbers and both use the sockets API.
Re: Report on last cmd
shove off, troll ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on last cmd
On Monday 07 October 2002 02:21 am, Rune Kristian Viken wrote: Monday, ben wrote: shove off, troll Uh.. WHAT? I'm not sure why you're calling me a troll, but I would appreciate it if you at least _attempted_ to be a tad more polite. i'd appreciate it if you could at least be consistent in what you send to the list and to my address. the fact that there is an inconsistency merely reinforces my prior response. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on last cmd
On Monday 07 October 2002 04:14 am, Rune Kristian Viken wrote: Ben wrote: shove off, troll I'm not sure why you're calling me a troll, but I would appreciate it if you at least _attempted_ to be a tad more polite. i'd appreciate it if you could at least be consistent in what you send to the list and to my address. the fact that there is an inconsistency merely reinforces my prior response. Eh? You sent me a private email, and got a private answer. You sent one answer to the mailinglist, and got one answer there. What exactly is the problem with that? Or with you for that matter? Here I try to help the guy that asked the question, that is 'Glen Tapley' - and you go ahead and flame me / call me a troll? What on earth is wrong with you? Is it suddenly a crime to ask people to read up on something? Running Linux which I recomended is a _great_ book to learn the basics of Linux, at least in my opinion. Which I was so unkind to recomend to other people. Or is it a crime to recomend what people should search for, when you don't have a personal favorite to recommed? Jeeez, thanks for flaming me for trying to be helpful. you've done the same again. you send me a different mailing to the one you send to the list. what's the point of that inconsistency? you're not proving me wrong. i can post them all here but i don't want to bore the list with your fallaciousness. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on last cmd
shove off, troll ben
Re: Report on last cmd
On Monday 07 October 2002 02:21 am, Rune Kristian Viken wrote: Monday, ben wrote: shove off, troll Uh.. WHAT? I'm not sure why you're calling me a troll, but I would appreciate it if you at least _attempted_ to be a tad more polite. i'd appreciate it if you could at least be consistent in what you send to the list and to my address. the fact that there is an inconsistency merely reinforces my prior response. ben
Re: Report on last cmd
On Monday 07 October 2002 04:14 am, Rune Kristian Viken wrote: Ben wrote: shove off, troll I'm not sure why you're calling me a troll, but I would appreciate it if you at least _attempted_ to be a tad more polite. i'd appreciate it if you could at least be consistent in what you send to the list and to my address. the fact that there is an inconsistency merely reinforces my prior response. Eh? You sent me a private email, and got a private answer. You sent one answer to the mailinglist, and got one answer there. What exactly is the problem with that? Or with you for that matter? Here I try to help the guy that asked the question, that is 'Glen Tapley' - and you go ahead and flame me / call me a troll? What on earth is wrong with you? Is it suddenly a crime to ask people to read up on something? Running Linux which I recomended is a _great_ book to learn the basics of Linux, at least in my opinion. Which I was so unkind to recomend to other people. Or is it a crime to recomend what people should search for, when you don't have a personal favorite to recommed? Jeeez, thanks for flaming me for trying to be helpful. you've done the same again. you send me a different mailing to the one you send to the list. what's the point of that inconsistency? you're not proving me wrong. i can post them all here but i don't want to bore the list with your fallaciousness. ben
Re: Report on last cmd
On Friday 04 October 2002 04:03 am, Glen Tapley wrote: Hello I have been having a lot of trouble with my sendmail setup, someone is using my system. I have found that when I run the last cmd, I find a lot of strange entries such as ftp ftp p50852BD8.dip.t- Sun Oct 6 03:57 - 03:57 (00:00) ftp ftp p508ECDDA.dip.t- Sun Oct 6 03:37 - 03:37 (00:00) ftp ftp 212.171.38.1 Sat Oct 5 23:16 - 23:16 (00:00) ftp ftp 210.23.10.25 Sat Oct 5 18:40 - 18:40 (00:00) Can anyone tell me what these are, are they the result of programs accessing my TCP/IP addresses? the first ip address seems to be relaying across interbusiness.it, and the second may well be an unallocated ip address belong to super.net.sg unless you can think of a good reason why anyone should think they have a legitimate reason to connect to you in that manner, you might want to get in touch with both of those to let them know what's going on--especially super.net, since they run one of the main gateways in singapore and will surely want to know about anyone spoofing their ip's. i just tried an ftp connection to you and an anonymous login was rejected, so it's unlikely that anybody has done any harm there. the incidents in your sendmail logs are probably part of a port scan. you should make sure that the rest of your system is solid. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Report on last cmd
On Friday 04 October 2002 04:03 am, Glen Tapley wrote: Hello I have been having a lot of trouble with my sendmail setup, someone is using my system. I have found that when I run the last cmd, I find a lot of strange entries such as ftp ftp p50852BD8.dip.t- Sun Oct 6 03:57 - 03:57 (00:00) ftp ftp p508ECDDA.dip.t- Sun Oct 6 03:37 - 03:37 (00:00) ftp ftp 212.171.38.1 Sat Oct 5 23:16 - 23:16 (00:00) ftp ftp 210.23.10.25 Sat Oct 5 18:40 - 18:40 (00:00) Can anyone tell me what these are, are they the result of programs accessing my TCP/IP addresses? the first ip address seems to be relaying across interbusiness.it, and the second may well be an unallocated ip address belong to super.net.sg unless you can think of a good reason why anyone should think they have a legitimate reason to connect to you in that manner, you might want to get in touch with both of those to let them know what's going on--especially super.net, since they run one of the main gateways in singapore and will surely want to know about anyone spoofing their ip's. i just tried an ftp connection to you and an anonymous login was rejected, so it's unlikely that anybody has done any harm there. the incidents in your sendmail logs are probably part of a port scan. you should make sure that the rest of your system is solid. ben
Re: SubRPC vulnerability: is Debian libc6 affected?
It looks like it is fixed in glibc 2.2.5-8, but again, it never made into official announcement. On woody, I believe Ben have been already working, but I don't know its status. Ben? Should I go ahead for woody? Woody and potato are already uploaded to security.d.o. It's in their hands now, and I suspect the hold up is getting it to auto-compile on all the archs. -- Debian - http://www.debian.org/ Linux 1394 - http://linux1394.sourceforge.net/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Fwd: RAZOR advisory: Linux util-linux chfn local root vulnerability
On Monday 29 July 2002 12:39 pm, Wichert Akkerman wrote: Previously Albert Cervera Areny wrote: I suppose this vulnerability affects also debian. I've already changed the setuid bit in chfn and chsh though it is supposed to be difficult to exploit. Debian doesn't use chfn friends from util-linux. when you say 'doesn't use,' do you perhaps mean 'never invokes'? because: # find / -name chfn /usr/bin/chfn /etc/pam.d/chfn and i'm damn sure i didn't put it there all by myself. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: RAZOR advisory: Linux util-linux chfn local root vulnerability
On Monday 29 July 2002 01:04 pm, Wichert Akkerman wrote: Previously ben wrote: when you say 'doesn't use,' do you perhaps mean 'never invokes'? because: # find / -name chfn /usr/bin/chfn /etc/pam.d/chfn Different implementation (from shadowutils iirc). Wichert. aah! thanks, wichert. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ot -- delivery errors
after both of my posts to the security list, i received delivery error messages in the form of: On Monday 29 July 2002 01:10 pm, [EMAIL PROTECTED] wrote: No such user: [EMAIL PROTECTED] is anyone else seeing the same or similar? ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beach towel
On Wednesday 15 May 2002 04:26 pm, Nathan Ridge wrote: Could be handy I spose if a server caught on fire, could throw a couple of towels on top to smoother the fire :) there's also the fact that we can be secure in the knowledge that linda has picked up the beach towel slack problem in damn near every debian related list in the world. i mean, who knew, before now, that we even needed 100% cotton velour to get the job done? hopefully debian-bugs got the same update. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: beach towel
On Wednesday 15 May 2002 04:26 pm, Nathan Ridge wrote: Could be handy I spose if a server caught on fire, could throw a couple of towels on top to smoother the fire :) there's also the fact that we can be secure in the knowledge that linda has picked up the beach towel slack problem in damn near every debian related list in the world. i mean, who knew, before now, that we even needed 100% cotton velour to get the job done? hopefully debian-bugs got the same update. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#126441: [security] What's being done?
Ben is merely behind with updating the BTS, by the looks of it... Can't close it till I fix woody/sid too. Which will be when 2.2.5 is released (days). -- .--===-=-==-=---==-=-. / Ben Collins--Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Apt-get is insecure
debsign is a part of devscripts. It looks to be present even in Potato. - Ben On Thu, Dec 13, 2001 at 05:37:42PM +0200, Samuli Suonpaa blathered thusly: Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Alexander Karelas wrote: RedHat uses a PGP signature scheme. What are we doing about it? apt-get install debsign $ sudo apt-get install debsign Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package debsign Ok, so it's not in Woody. Let's try Sid, then. $ sudo apt-get install debsign/unstable Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package debsign -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ msg04786/pgp0.pgp Description: PGP signature
Re: Apt-get is insecure
debsign is a part of devscripts. It looks to be present even in Potato. - Ben On Thu, Dec 13, 2001 at 05:37:42PM +0200, Samuli Suonpaa blathered thusly: Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Alexander Karelas wrote: RedHat uses a PGP signature scheme. What are we doing about it? apt-get install debsign $ sudo apt-get install debsign Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package debsign Ok, so it's not in Woody. Let's try Sid, then. $ sudo apt-get install debsign/unstable Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package debsign -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ pgpyIWQjiVeQH.pgp Description: PGP signature
Re: buffer overflow in /bin/gzip?
On Wed, 21 Nov 2001, Guillaume Morin wrote: Dans un message du 20 nov à 23:33, Anders Gjære écrivait : in gzip.c the line: strcpy(nbuf,dir); should maybe be replaced with: strncpy(nbuf, dir,sizeof(nbuf)); gzip runs with user privileges, therefore this is not a security problem. That is extremely sill and short sighted. What happens if root runs gzip, for example root unzipping a tar ball for some new software. To say it runs at user privileges *does not* stop it being a security problem. Benno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: buffer overflow in /bin/gzip?
On Wed, 21 Nov 2001, Guillaume Morin wrote: Dans un message du 20 nov à 23:33, Anders Gjære écrivait : in gzip.c the line: strcpy(nbuf,dir); should maybe be replaced with: strncpy(nbuf, dir,sizeof(nbuf)); gzip runs with user privileges, therefore this is not a security problem. That is extremely sill and short sighted. What happens if root runs gzip, for example root unzipping a tar ball for some new software. To say it runs at user privileges *does not* stop it being a security problem. Benno
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ pgpaNM6YoSBtN.pgp Description: PGP signature
Re: Port Scan for UDP
On Sat, Oct 20, 2001 at 09:22:57PM -0700, tony mancill blathered thusly: A good way to find out what process is listening on a port is to load the lsof package and use lsof -i (as root so that you'll see everything). I find that fuser is more convenient at times - fuser -v -n udp port returns the process(es) listening on the named UDP port. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ PGP signature
Re: Need Help with the Debian Securing Manual (contributions accepted)
On 0, Javier Fern?ndez-Sanguino Pe?a [EMAIL PROTECTED] blathered thusly: On Sun, Sep 23, 2001 at 06:31:24PM -0700, Nicole Zimmerman wrote: Forbidden You don't have permission to access /doc/manuals/securing-debian-howto/ on this server. ?? Works fine for me, just tried it. Are you sure is not a problem with your proxy? I too get the 403 forbidden error. I imagine this does not affect all of the servers that comprise www.debian.org, and those that are unlucky enough to get the affected one in their DNS lookup get the error. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need Help with the Debian Securing Manual (contributions accepted)
On 0, Javier Fern?ndez-Sanguino Pe?a [EMAIL PROTECTED] blathered thusly: On Sun, Sep 23, 2001 at 06:31:24PM -0700, Nicole Zimmerman wrote: Forbidden You don't have permission to access /doc/manuals/securing-debian-howto/ on this server. ?? Works fine for me, just tried it. Are you sure is not a problem with your proxy? I too get the 403 forbidden error. I imagine this does not affect all of the servers that comprise www.debian.org, and those that are unlucky enough to get the affected one in their DNS lookup get the error. -- /-- | Ben Staffin gpg key: http://darkskie.net/~benley/pgp.txt | --/
Re: Is ident secure?
Layne [EMAIL PROTECTED] writes: OK they just keep coming. I had 8 messages at 11:00PM , all of who I knew. Now I have 227 in my in box of solicitors all of who I didn't subscribe to. And you wonder why I get mad. Did it ever occur to you that maybe it's not acceptable to harass everyone on the mailing list just because someone subscribed you? Try to act a little more mature and follow the unsubscribe instructions like a normal person would. The only way to subscribe in the first place is by replying to a confirmation message, so you (or someone who has access to your account; has your account security been compromised?) must have subscribed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Layne (was: Re: Is ident secure?)
Paul Visscher [EMAIL PROTECTED] writes: Ed Street [EMAIL PROTECTED] said: Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... I just submitted his address to [EMAIL PROTECTED], hopefully they'll LART him.
Re: Is ident secure?
Layne [EMAIL PROTECTED] writes: OK they just keep coming. I had 8 messages at 11:00PM , all of who I knew. Now I have 227 in my in box of solicitors all of who I didn't subscribe to. And you wonder why I get mad. Did it ever occur to you that maybe it's not acceptable to harass everyone on the mailing list just because someone subscribed you? Try to act a little more mature and follow the unsubscribe instructions like a normal person would. The only way to subscribe in the first place is by replying to a confirmation message, so you (or someone who has access to your account; has your account security been compromised?) must have subscribed.
Re: Layne (was: Re: Is ident secure?)
Paul Visscher [EMAIL PROTECTED] writes: Ed Street [[EMAIL PROTECTED]] said: Already sent mail to the list admin on the bottom of each email. I just submitted his address in at http://www.debian.org/MailingLists/unsubscribe to be unsubscribed, hopefully that will work... I just submitted his address to [EMAIL PROTECTED], hopefully they'll LART him. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote: a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. well nearly... at least you can prevent new or unknown process/files from acessing stuff. If there is an exploit for an existing piece of software you are back at square one. The advantage is extremely granular control: a program at a specific inode can be given capabilities while everything else has them refused. the disadvantage is that you end up with a million little holes (complexity) fortunately the files that have these added capabilities are also protected (from trojaning - buffer overruns etc still work) the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. yes it is possible with lids, but it is a _lot_ harder: processes can be hidden. binaries RO (trojaning is difficult) logs append /etc/somefile can only be read when you allow it. system adminsitrator == root cracker == root cracker==root sysadmin==root+LIDS_password if someone can sniff me typing in my lids password (encrypted in the kernel) then I am stuffed. In short Lids can be a pain to set up, but would also be a pain to crack, especially if the cracker doesn't know exactly which rules I have set up. a good cracker could do it. btw I notice that they are still working on fork bomb protection. that would be nice :) --
Re: A question about Knark and modules
On Sun, Jun 17, 2001 at 07:55:40PM -0800, Ethan Benson wrote: a bit. lids makes system adminsitration utterly impossible. unless you leave enough holes open which an attacker can use to bypass it all. well nearly... at least you can prevent new or unknown process/files from acessing stuff. If there is an exploit for an existing piece of software you are back at square one. The advantage is extremely granular control: a program at a specific inode can be given capabilities while everything else has them refused. the disadvantage is that you end up with a million little holes (complexity) fortunately the files that have these added capabilities are also protected (from trojaning - buffer overruns etc still work) the thing is once you make exceptions for the system adminsistrator to use to maintain the you open the holes the attacker needs to trojan your system and to remove the additional obsticales you installed. yes it is possible with lids, but it is a _lot_ harder: processes can be hidden. binaries RO (trojaning is difficult) logs append /etc/somefile can only be read when you allow it. system adminsitrator == root cracker == root cracker==root sysadmin==root+LIDS_password if someone can sniff me typing in my lids password (encrypted in the kernel) then I am stuffed. In short Lids can be a pain to set up, but would also be a pain to crack, especially if the cracker doesn't know exactly which rules I have set up. a good cracker could do it. btw I notice that they are still working on fork bomb protection. that would be nice :) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X tcp listening
Jim Breton [EMAIL PROTECTED] writes: On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: If an user creates his own $HOME/.xserverrc, it overrides the system wide xserverrc. So make /usr/bin/X11/X a wrapper for the real X. Problem with this is, if you upgrade or re-install the package containing it, it will get replaced by the package's copy and you will have to do this again. dpkg-divert is your friend. -- MONO - Monochrome Emulation This field is used to store your favorite bit. --FreeVGA Attribute Controller Reference -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: X tcp listening
Jim Breton [EMAIL PROTECTED] writes: On Mon, May 28, 2001 at 01:46:07PM +0200, Tomasz Olszewski wrote: If an user creates his own $HOME/.xserverrc, it overrides the system wide xserverrc. So make /usr/bin/X11/X a wrapper for the real X. Problem with this is, if you upgrade or re-install the package containing it, it will get replaced by the package's copy and you will have to do this again. dpkg-divert is your friend. -- MONO - Monochrome Emulation This field is used to store your favorite bit. --FreeVGA Attribute Controller Reference
Re: strange file
On Mon, Nov 20, 2000 at 11:33:32AM +0100, Virginie-ML wrote: On Mon, Nov 20, 2000 at 11:26:28AM +0100, Johan Bergström wrote: # cat /.esd_auth [EMAIL PROTECTED]:[EMAIL PROTECTED]@\x9e^@@ There is only this line in ... Could anybody reassure me please ?:) I belive its part of the Enlightenment Sound Daemon. Some sort of X magic cookie or something. Don't you find curious that a configuration file appears in / and looks like a binary file ? Furthermore, I use windowmaker :-o I have this file in the home directories of all my users that use ESD...could it have somehow gotten into root by accident?
Re: funny rpc.statd events
Daniel Jacobowitz [EMAIL PROTECTED] writes: This was fixed a month or two before potato was released. I've seen those too, on up-to-date woody, so I don't think it really got fixed. On Tue, Oct 10, 2000 at 09:09:52PM -0500, Herbert Ho wrote: hi guys. i have logcheck installed so i got this message tonight: =20 (sorry about the long lines, its the way it came to me) =20 Unusual System Events =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Oct 10 19:31:37 thosolin=20 Oct 10 19:31:37 thosolin /sbin/rpc.statd[125]: gethostbyname error for ^X= =F7=FF=BF^X=F7=FF=BF^Y=F7=FF=BF^Y=F7=FF=BF^Z=F7=FF=BF^Z=F7=FF=BF^[=F7=FF=BF= ^[=F7=FF=BF%8x%8x%8x%8x%8x%8x%8x%8x%8x%236x%n%137x%n%10x%n%192x%n\220\220\2= 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\22= 0\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2= 20\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\= 220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220= \220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\220\2! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the security of e-mails
We'll soon be getting braindead crypto laws in the UK if the RIP bill goes through. RIP details at http://www.stand.org.uk/ On Fri, 26 May 2000, Alexander Hvostov wrote: Sergio, That's what GPG and a good MUA like Pine is for. Let's see Big Brother crack 1024-bit public key crypto anytime this decade... I know you can't legally do this in France; if you have a desire for your email to be private, then I suggest moving to a country whose crypto policies are not brain-dead, such as the USA, Canada, the UK, and so on. Regards, Alex. --- PGP/GPG Fingerprint: EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM d- s:+ a--- C UL P L+++ E W++ N o-- K- w O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+ G e-- h++ r--- y --END GEEK CODE BLOCK-- Ben White 01473 403020 KeConnect Internet http://www.keconnect.co.uk/
