Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)
* [Wed, Apr 03, 2024 at 11:11:20PM +0100] Samuel Henrique: On the proposed solution I also mention that we can use the "(free text comment)" section to indicate that, while sticking to "not-affected", this would simplify things as no new value is needed. But parsing the cases where only the sources contain the vulnerable code might be a bit harder. Not only it's the parsing harder, but it also is a "lesser" warning than an "affected" status. I'm curious though as to what is the usecase of that, no other Linux distribution specifies the case where only the source carries the vulnerability. My impression is that Debian currently does, even if imperfectly, by marking the package as vulnerable and setting the unimportant bit. What would be the need for this as a user? If this is a need you have, could you clarify it, please? Definitively it isn't a need, I would call it an expectation. I used to recompile a lot of Debian packages, usually for backporting, and I guess I've always assumed that a package marked not-vulnerable would not bring the vulnerability back when, e.g., linked against a previous version of a library. Or, e.g., I would not consider not-vulnerable a package shipping a malicious example script. But I concede that creating a binary-only tag has its own issues. For example, a vulnerability could only affect some architectures, and that means you should now differentiate not only per package name and "form" (source or binary), but also per architecture. Cheers, Gian Piero.
Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)
* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique: # Alternative solutions: If we really want to distinguish the case when we don't produce any affected packages but the source contains the vulnerability (a build with different flags might result in an affected package), we can create a new tag to show this: not-affected-build-artifacts. This. Just marking the CVE as not-affected does not distinguish between deb and deb-src, that are still part of (and shipped by) Debian. Cheers, Gian Piero.
Re: xz backdoor prevention and hosts.deny?
* [Sun, Mar 31, 2024 at 09:28:46PM +] Nick Sal:
With respect to debian testing, assume we filter SSH access only to a
subnet using the files host.{deny,allow} (see below).
Would this prevent the attack if a malicious payload was not sent from
the allowed subnet?
I've not seen any reference to this. One could argue that tcpwrappers'
check should happen in an early stage, so it could have helped. But
that's just speculation and I would consider the system vulnerable
unless someone knowledgeable (I'm not) says otherwise.
Moreover, would it have helped if additionally allowing only public-key
authentication for SSH?
All sources I've read agree that this was not sufficient (actually, the
malicious code resided in the function verifying the key signatures).
Best,
Gian Piero.
Re: Upcoming stable point release (12.6)
* [Fri, Mar 29, 2024 at 10:24:09PM +] Adam D. Barratt: Due to recent events, the point release has been postponed. A new date will be announced when possible. Given the centrality of xz, and standing that AFAIK the intricacies of the attack are not yet fully understood, should we expect a complete rebuild of the whole pool against an audited version? Maybe only the testing/sid/experimental pool? Thanks, Gian Piero.
Re: Bullseye security.debian.org codename misconfigured?
* [Sat, Jan 22, 2022 at 11:09:20AM +0100] Stefan Fritsch: I think the bullseye-security codename should be "bullseye" instead. Or am I missing something The repo naming scheme has changed with bullseye. I do not have the announcement at hands, however the old '/updates' is now '-security', see https://www.debian.org/security/. Hth, Gian Piero.
Re: deb.debian.org vs security.debian.org
* [Thu, Aug 19, 2021 at 01:25:00AM -0500] Daniel Lewart:
Is there a preferred sources.list URI for the Debian security
repository between:
* http://deb.debian.org/debian-security
* http://security.debian.org/debian-security
I asked in debian-devel and received two replies:
* https://lists.debian.org/debian-devel/2021/08/msg00166.html
* https://lists.debian.org/debian-devel/2021/08/msg00167.html
* https://lists.debian.org/debian-devel/2021/08/msg00172.html
but no consensus.
AFAIK, what Peter said ("the security updates repository is
intentionally not supposed to be mirrored") was true for a long time,
but isn't since a while. I guess the bandwidth requirements became too
onerous. As pabs said, currently "both of these URLs point at the Fastly
CDN, so they are equivalent". Just pick one.
Ciao,
Gian Piero.
Re: fun with mailinglists (was Re: Is chromium updated?)
* [Fri, Nov 13, 2020 at 05:26:56AM -0500] John Runyon: Why do we have such messages on the security mailing list? Is there a way to get actual security team announcements without all this spam? That's a job for debian-security-announce@l.d.o (please note the '-announce' suffix) Ciao, Gian Piero.
Re: Checking for services to be restarted on a default Debian installation
* [Mon, Sep 01, 2014 at 08:48:25PM +0200] Thijs Kinkhorst: [needrestart] - Do people agree that this would be something that's good to have in a default installation? Are there drawbacks? I like needrestart and I added it to my standard toolbox since its admission in Debian (well, it took some versions for being really usable with a readline front-end), so I second this proposal. Please however note that it is not a replacement for checkrestart or a plain lsof, as it doesn't care for programs that don't have an init script. Maybe for such programs needrestart should warn and advice that a manual intervention is required, in the same way it currently does for kernel upgrades ? Ciao, Gian Piero. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140903081758.gb4...@butterfly.fdc.rm-rf.it
Re: Hash algorithms used by APT to verify authenticity of installed files.
* [Fri, Apr 29, 2011 at 07:57:28PM +0200] Tomasz Wozowicz:
ForceHash sha256; // hashmethod used for expected hash: sha256,
sha1 or md5sum
It doesnt say what will happen if the expected hash is unavaible-
maybe it will just use weaker hash as fallback?
No. After all, it's named ForceHash not PreferHash. :)
I think that issues regarding security should be descriped clearly and
exhaustively. Many people like me are not coders and dont understand
source code :(
I'm neither a coder, anyway the source seems pretty clear so I think
it's worth reading if you care enough.
In apt-pkg/acquire-item.cc:1683 you can find the following lines:
if (ForceHash.empty() == false)
{
if(stringcasecmp(ForceHash, sha256) == 0)
ExpectedHash = HashString(SHA256, Parse.SHA256Hash());
else if (stringcasecmp(ForceHash, sha1) == 0)
ExpectedHash = HashString(SHA1, Parse.SHA1Hash());
else
ExpectedHash = HashString(MD5Sum, Parse.MD5Hash());
}
else
{
string Hash;
if ((Hash = Parse.SHA256Hash()).empty() == false)
ExpectedHash = HashString(SHA256, Hash);
else if ((Hash = Parse.SHA1Hash()).empty() == false)
ExpectedHash = HashString(SHA1, Hash);
else
ExpectedHash = HashString(MD5Sum, Parse.MD5Hash());
}
that - apart from bugs or further manipulations of the involved variables (to
be honest I haven't investigated further) - should answer your questions.
Ciao,
Gian Piero.
--
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/20110502065719.ga29...@caimano.fdc.rm-rf.it
Re: Hash algorithms used by APT to verify authenticity of installed files.
* [Sat, Apr 23, 2011 at 12:04:33PM +0200] Quequanys: Does it fallback to weaker algorithm, if the hash made with stronger one is not avaible? Is there a way to force APT to use only selected algorithms so APT only accepts files verified by choosen algorithms, and rejects files when required hashes are unavaible? Acquire::ForceHash Could you point me to specific portions of documentation that covers this issue? I use to consider /usr/share/doc/apt/examples/configure-index.gz as the best source of informations regarding apt parameters. Ciao, Gian Piero. -- 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/20110423162108.ga6...@caimano.fdc.rm-rf.it
Re: iptables and nmap
Il giorno Thu, 7 Jun 2007 15:51:51 +0200 Joan Hérisson [EMAIL PROTECTED] ha scritto: So I added this rule : iptables -A tcp_packets -p TCP -i eth1 -s 0/0 --dport 8080 -j allowed where eth1 is the way toward my local network Results: - The server is still unreachable. - When I do nmap localhost, I have port 80 open but not 8080. - When I comment out the line for port 80 in firewall-start and I restart firewall, I do nmap localhost, port 80 is still open. Just a further note: you've opened ( or tried to, don't know if the action was successful ) the port on interface eth1, but you're testing the rule on localhost ( loopback interface lo ). Ciao, Gian Piero.
Re: Large, constant incoming traffic
Il gio, 2004-05-13 alle 19:53, Kjetil Kjernsmo ha scritto: [...] 19:41:32.083993 217.77.34.162.2090 226.58.55.41.1434: udp 376 [ttl 1] 19:41:32.192344 217.77.34.162.2090 234.247.236.46.1434: udp 376 [ttl 1] A switched lan, I see ;) It can be slammer [1] (if so, I guess why the ISP tech is so busy :) As you run snort, the eth is probably in promiscuous mode. I think this is the reason you see ifconfig counter increasing (though the packets aren't leading to your server). This and a non-switched lan, of course. Ciao, Gian Piero. [1] http://enterprisesecurity.symantec.com/content.cfm?articleid=3261EID=0
Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto: we won't hide problems ... Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Shouldn't the delayed disclosure be regarded a a sort of, at least partially, infringement of the Debian manifesto ? Obviously, I'm referring to the quoted statement. Be warned that I'm not saying to avoid delaying of DSAs, I'm only interested in your opinions about compatibility between manifesto and the way security bugs are treated ( and opinions about how you can avoid the problem, if any ). Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. You're right. I've exchanged manifesto and social contract, and my search was useless. Sorry for that. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto: we won't hide problems ... Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Shouldn't the delayed disclosure be regarded a a sort of, at least partially, infringement of the Debian manifesto ? Obviously, I'm referring to the quoted statement. Be warned that I'm not saying to avoid delaying of DSAs, I'm only interested in your opinions about compatibility between manifesto and the way security bugs are treated ( and opinions about how you can avoid the problem, if any ). Ciao, Gian Piero.
Some clarifications about the Debian-security-HOWTO
From http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6 When a security fix is prepared, packages are prepared for unstable and the patch is back ported to stable (since stable is usually some minor or major versions behind). Packages for the stable distribution are more thoroughly tested than unstable, since the latter might just provide the latest upstream release. Security updates are available immediately for both branches (but not yet for the testing branch). But this is not always true. Sometimes the DSA reports For the unstable distribution (sid) these problems will be fixed soon. Why this ? Ok, sometimes the sid package may need a longer testing period, and maybe sometimes a maintainer (or the DST) can consider preferable waiting for the packaging of a new upstream release, but are these the only reasons ? Are the fixes *always* be applied to sid packages and then backported ? This method sounds a bit odd to me, especially when uploading in sid is delayed until a new upstream version is packaged. If no (new) bugs are detected in the unstable version of the package, it moves to testing after several days (usually over a week). However, this does depend on the release state of the distribution. Uploads that fix a security hole should have the priority set to high, and this should reduce the transition delay to less than a week [1], shouldn't it? Ciao, Gian Piero. [1] Usually. I mean if no other problems, as dependencies or similar, arise.
Re: Delayed disclosure and Debian manifesto (was Re: DSA 438 - bad server time, bad kernel version or information delayed?)
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto: Well, I really don't want to feed a troll, but this is a theme I'm wondering about from a while... Then do a web search. It's been discussed before in way too much detail and repeating the arguments just brings out the trolls. You're right. I've exchanged manifesto and social contract, and my search was useless. Sorry for that. Ciao, Gian Piero.
Re: DSA-361-2
Il lun, 2003-08-11 alle 02:58, Matt Zimmerman ha scritto: I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been released in december 2001 2.2.2-6woody2 is a later version than 2.2.2-6. 2.2.2-6 has the bugs, 2.2.2-6woody2 has the fixes. 2.2.2-6 has been released on dec 13 2001, 2.2.2-7 on dec 14 2001 (following the changelog), so 2.2.2-6woody2 should be dated between these 2 days, am i right? , so i've to assume fake vulnerabilities (CAN 2003-... ), or at least they don't apply to deb packages... but then 2.2.2-13.woody.8 what is for? I do not understand the problem. DSA-361-1 states that the vulnerabilities reported have been fixed in 2.2.2-13.woody.8 (and this is the version you can find in the repository)... DSA-361-2 is the same advisory, except that it states that the vulnerabilities have been fixed in 2.2.2-6woody2... and i think that's someway strange that 2 vulnerabilities from this year have been addressed almost 2 years ago (well, not impossible with debian :) )... but then, what's the purpose of 2.2.2-13.woody.8? Really, i suspect a typo in the advisory. Or more likely, i haven't understood too much about the whole thing. Hope i've been clear enough (and forgive me for my little confidence with english). Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DSA-361-2
Hi all, can anyone explain me the DSA-361-2? Does it mean that the vulnerabilities reported were already addressed in woody in version 2.2.2-6woody2 ? I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been released in december 2001, so i've to assume fake vulnerabilities (CAN 2003-... ), or at least they don't apply to deb packages... but then 2.2.2-13.woody.8 what is for? Thanks, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-361-2
Il lun, 2003-08-11 alle 12:22, Gian Piero Carrubba ha scritto: DSA-361-1 states that the vulnerabilities reported have been fixed in 2.2.2-13.woody.8 (and this is the version you can find in the repository)... DSA-361-2 is the same advisory, except that it states that the vulnerabilities have been fixed in 2.2.2-6woody2... Foolish me... DSA-361-1 is about kdelibs, DSA-361-2 is about kdelibs-*crypto*... didn't notice this _little_ difference... Sorry for that. Ciao, Gian Piero. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DSA-361-2
Il lun, 2003-08-11 alle 02:58, Matt Zimmerman ha scritto: I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been released in december 2001 2.2.2-6woody2 is a later version than 2.2.2-6. 2.2.2-6 has the bugs, 2.2.2-6woody2 has the fixes. 2.2.2-6 has been released on dec 13 2001, 2.2.2-7 on dec 14 2001 (following the changelog), so 2.2.2-6woody2 should be dated between these 2 days, am i right? , so i've to assume fake vulnerabilities (CAN 2003-... ), or at least they don't apply to deb packages... but then 2.2.2-13.woody.8 what is for? I do not understand the problem. DSA-361-1 states that the vulnerabilities reported have been fixed in 2.2.2-13.woody.8 (and this is the version you can find in the repository)... DSA-361-2 is the same advisory, except that it states that the vulnerabilities have been fixed in 2.2.2-6woody2... and i think that's someway strange that 2 vulnerabilities from this year have been addressed almost 2 years ago (well, not impossible with debian :) )... but then, what's the purpose of 2.2.2-13.woody.8? Really, i suspect a typo in the advisory. Or more likely, i haven't understood too much about the whole thing. Hope i've been clear enough (and forgive me for my little confidence with english). Ciao, Gian Piero.
Re: DSA-361-2
Il lun, 2003-08-11 alle 12:22, Gian Piero Carrubba ha scritto: DSA-361-1 states that the vulnerabilities reported have been fixed in 2.2.2-13.woody.8 (and this is the version you can find in the repository)... DSA-361-2 is the same advisory, except that it states that the vulnerabilities have been fixed in 2.2.2-6woody2... Foolish me... DSA-361-1 is about kdelibs, DSA-361-2 is about kdelibs-*crypto*... didn't notice this _little_ difference... Sorry for that. Ciao, Gian Piero.
DSA-361-2
Hi all, can anyone explain me the DSA-361-2? Does it mean that the vulnerabilities reported were already addressed in woody in version 2.2.2-6woody2 ? I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been released in december 2001, so i've to assume fake vulnerabilities (CAN 2003-... ), or at least they don't apply to deb packages... but then 2.2.2-13.woody.8 what is for? Thanks, Gian Piero.
Re: Snort exploit in wild.
Il ven, 2003-04-25 alle 11:19, David Ramsden ha scritto: Noticed on vil.mcafee.com that a proof of concept exploit for Snort to exploit the vuln. found in v1.8 through to 1.9.1. up to 2.0rc1 as reported by cert What's the status of a patch from Debian Security? No DSA yet either. I know this has been brought up a few times already but now an exploit exists in the wild. don't know if the debian package is affected, however it should As a workaround, I could disable snort (granted) but also, how can I use /etc/apt/preferences to update /just/ snort to a non-vuln. version from another branch (unstable/testing)? What line do I need in /etc/apt/sources.list? And how easy is it to downgrade to the stable version if something goes wrong or a patch is released from Debian? don't do it... unstable/snort depends on a libc version not available in stable, and maybe there are some other unresolved dependencies... instead get the deb-src and try to recompile... i think it's not so linear, but it should work... in the meantime (from the cert advisory): Disable affected preprocessor modules Sites that are unable to immediately upgrade affected Snort sensors may prevent exploitation of this vulnerability by commenting out the affected preprocessor modules in the snort.conf configuration file. To prevent exploitation of VU#139129, comment out the following line: preprocessor stream4_reassemble To prevent exploitation of VU#916785, comment out the following line: preprocessor rpc_decode: 111 32771 After commenting out the affected modules, send a SIGHUP signal to the affected Snort process to update the configuration. Note that disabling these modules may have adverse affects on a sensor's ability to correctly process RPC record fragments and TCP packet fragments. In particular, disabling the stream4 preprocessor module will prevent the Snort sensor from detecting a variety of IDS evasion attacks. Regards, Gian Piero. PS: about the pinning question, please read the apt-howto
