RE: [SECURITY] [DSA 3107-2] subversion regression update
N/A -Original Message- From: Florian Weimer [mailto:f...@deneb.enyo.de] Sent: Saturday, December 20, 2014 9:56 PM To: debian-security-annou...@lists.debian.org Subject: [SECURITY] [DSA 3107-2] subversion regression update Importance: High -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - - Debian Security Advisory DSA-3107-2 secur...@debian.org http://www.debian.org/security/Florian Weimer December 20, 2014 http://www.debian.org/security/faq - - Package: subversion Debian Bug : 773610 The previous subversion security update, DSA-3107-1, introduced a regression which causes Apache httpd to fail to start due to an undefined symbol dav_svn__new_error in configurations which used mod_dav_svn. For the stable distribution (wheezy), this problem has been fixed in version 1.6.17dfsg-4+deb7u8. We recommend that you upgrade your subversion 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.4.10 (GNU/Linux) iQEcBAEBAgAGBQJUleccAAoJEL97/wQC1SS+aBoH/0K6P717Tnd5bdYjVgiiG+ez MkfD/vizDA4WCDTNgz4/1zGPpS71xVwzWm2AUciz4SQerfbCzl6/JcooUxJsC7XG FmVvgHumDQQN3WfXL7+iMc829lPD9JB6W/hkVyqQbOeuLYH0I6WMbHq/XW38Be3w ZskAn/fUXkTXx8Xw+rozOSZMREgWHXsp/tCmLVP7ib19mbb7RG4G81pdw382vCej EXlyKvJmml0VNozdHhpj1Km74Iu0G7avHX1TXAwdVuvJeOSoRmLRkO25cplx30+Q PoSByew5r3NqBEMMtOVtAwWvSKvO2Q/fzogbY53AOmffZgv8amXXfVu/51Sue+0= =DicL -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/87r3vudoqx@mid.deneb.enyo.de anixe Polska sp. z o.o. z siedziba we Wroclawiu, ul. Grabiszynska 241a, 53-234 Wroclaw, zarejestrowana w Sadzie Rejonowym dla Wroclaw Fabryczna, VI Wydzial Gospodarczy Krajowego Rejestru Sadowego pod numerem KRS 008486, NIP: 899-24-09-480, o kapitale zakladowym wniesionym w calosci wynoszacym 105 000,00 zlotych i numerze rachunku bankowego: 06 2490 0005 4520 4818 7474. -- 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/b3e689b51699456bb522515cb4c7c...@satyr.intra.anixe.pl
RE: Is this a hacking attempt?
Hi, Van: paul.is.w...@gmail.com [mailto:paul.is.w...@gmail.com] Namens Paul Wise Fortunately, this works, but there are sites where doesn't. Do you have any examples of sites that still need Flash? Obviously flash game sites still need it but surely almost all of the web has moved away from it at this point? VMware based their new vSphere management interface around flash. The idea was that companies without Windows machines no longer need a Windows PC just to use the VMware client. All they need now is a machine with flash. ;-) Bonno Bloksma
[HITB-Announce] #HITB2015AMS Call for Papers 1st Round is Closing in 10 Days
Hi guys - Happy New Year! Just a reminder that the first selection round for submissions to HITB Security Conference 2015 in Amsterdam is closing at the end of January! That's T - 10 days and counting!!! === Date: 26th - 29th May 2015 Venue: De Beurs van Berlage Event Website: http://conference.hitb.org/hitbsecconf2015ams/ --- HITBSecConf is a deep-knowledge, highly technical conference and we're looking for material which is new, fresh and preferably something which hasn't been presented previously. In short, show us your 0days! Submission Deadlines: Round #1 selection: 1st February 2015 Round #2 selection: 1st March 2015 Submissions will be evaluated in 2 rounds. If all slots are filled in the first selection round, we will close CFP early so DON'T DELAY SUBMITTING! HITB CFP: http://cfp.hackinthebox.org/ === Each accepted submission will entitle the speaker(s) to accommodation for 3 nights / 4 days and travel expense reimbursement up to EUR1200.00 _per speaking slot_ Topics of interest include, but are not limited to the following: Cloud Security File System Security 3G/4G/WIMAX Security SS7/GSM/VoIP Security Security of Medical Devices Critical Infrastructure Security Smartphone / MobileSecurity Smart Card and Physical Security Network Protocols, Analysis and Attacks Applications of Cryptographic Techniques Side Channel Analysis of Hardware Devices Analysis of Malicious Code / Viruses / Malware Data Recovery, Forensics and Incident Response Hardware based attacks and reverse engineering Windows / Linux / OS X / *NIX Security Vulnerabilities Next Generation Exploit and Exploit Mitigation Techniques NFC, WLAN, GPS, HAM Radio, Satellite, RFID and Bluetooth Security WHITE PAPER: If your presentation is short listed for inclusion into the conference program, a technical white paper must also be provided for review (3000 - 5000 words). Your submissions will be reviewed by The HITB CFP Review Committee: Charlie Miller (formerly Principal Research Consultant, Accuvant Labs) Katie Moussouris, Chief Policy Officer, HackerOne Marco Balduzzi, Lead Research Scientist, Trend Micro Itzik Kotler, Chief Technology Officer, Security Art Cesar Cerrudo, Chief Technology Officer, IOActive Jeremiah Grossman, Founder, Whitehat Security Andrew Cushman, Senior Director, Microsoft Saumil Shah, Founder CEO Net-Square Thanh 'RD' Nguyen, THC, VNSECURITY Alexander Kornburst, Red Database Fredric Raynal, QuarksLab Shreeraj Shah, Founder, BlueInfy Emmanuel Gadaix, Founder, TSTF Andrea Barisani, Inverse Path Philippe Langlois, TSTF Ed Skoudis, InGuardians Haroon Meer, Thinkst Chris Evans, Google Raoul Chiesa, TSTF/ISECOM rsnake, SecTheory Gal Diskin, Intel Skyper, THC Note: We do not accept product or vendor related pitches. If you would like to showcase your company's products or technology at HITB Haxpo (which also has it's own set of speaking slots), please email i...@haxpo.nl or conferencei...@hackinthebox.org to request for a sponsorship kit Regards, Hafez Kamal Hack in The Box (M) Sdn. Bhd 36th Floor, Menara Maxis Kuala Lumpur City Centre 50088 Kuala Lumpur, Malaysia Tel: +603-26157299 Fax: +603-26150088 -- 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/33kiaqzg-o4kv-aiqq-m7qy-3wzb0ng3a...@hackinthebox.org
Q: Best Practices for 3rd party APT sources for security considerations?
SUMMARY:
Q: Can a registered 3rd party repo spoof critical packages (e.g.
libc6) and have them installed on apt 'upgrade' operations?
Q: What are the best ways (configuration) to help manage 3rd party
repos to constrain their capabilities?
I have a growing number of users who want all sorts of 3rd party stuff
installed on their desktops (a few hundred), including things like
google chrome|earth, dropbox, etc. Keeping packages updated implies
adding sources.list entries, but...
Is it possible for a 3rd party repository/source added in
/etc/apt/sources.list.d/ to compromise a system by spoofing a new
(higher) version of a critical package, such as 'libc6'?
(aptitude update aptitude upgrade = here, let me install
that new 'libc6' from 'packages-r-us.biz')?
What within apt prevents a spoofage of this nature? (it's unclear to
me that there's any builtin protection against this)
Ultimately, this question is kind of moot, as the mere act of trusting
a 3rd party source for a package installation (or dpkg -i {file})
makes us all sitting ducks, opening your system up to ANY root
activity being performed via a '{pre,post}inst' scripted action or
malware contents -- including having an arbitrary package flat-out
replace libc.so.So a whole lotta faith is being put into that 3rd
party being benevolent, being security conscious in protection of
signing keys, and not ever getting hacked. (is this big elephant in
the room part of why there seems to be a dearth of any detailed Apt
configuration security best practices?) (debsums after the fact
might be a good thing to have configured just to warn when something
does get borked, but in the case of dynamic lib SOs -- nothing stops a
symlink diversion to an alternate .so either, which wouldn't get
reported, since the symlink is dynamically created outside the package
contents)
But, my real question is about how best to configure Apt for when you
*do* make the leap of faith to add a 3rd party source.
There's some question of whether not adding the PGP keys of the
source/package signers and having to manually intervene in the Apt
install warnings is a good idea to keep from accidentally
automatically installing something suspicious. (breaks
unattended-upgrades, obviously) Anybody do this?
Does it make sense to configure APT Preferences to allow only
DESIRED/KNOWN packages from that source to be installable.
I do that for Redhat/Yum via something like:
# Only let CFEngine be installed from EPEL
kwriteconfig --file /etc/yum.repos.d/epel.repo --group 'epel'
--key 'includepkgs' 'cfengine'
E.G. for Google packages, something like:
[/etc/apt/sources.list.d/google*.list]
deb http://dl.google.com/linux/chrome/deb/ stable main
deb http://dl.google.com/linux/earth/deb/ stable main
[/etc/apt/preferences.d/google.pref]
Package: google-earth-stable
Explanation: Allow google-earth-stable to be installed/upgraded
Pin: origin dl.google.com
Pin-Priority: 100
Package: google-chrome-stable
Explanation: Allow google-chrome-stable to be installed/upgraded
Pin: origin dl.google.com
Pin-Priority: 100
Package: *
Explanation: Disallow all other packages from dl.google.com
Pin: origin dl.google.com
Pin-Priority: -1000
lists# apt-cache policy google-chrome-stable
google-chrome-stable:
Installed: 39.0.2171.99-1
Candidate: 40.0.2214.91-1
Package pin: 40.0.2214.91-1
Version table:
40.0.2214.91-1 100
-1000 http://dl.google.com/linux/chrome/deb/ stable/main
amd64 Packages
*** 39.0.2171.99-1 100
100 /var/lib/dpkg/status
AFAICT, this preferences setting *should* disallow 'dl.google.com'
from ever being able to offer a spoofed system package such as
'libc6', allowing that source to only provide the packages
'google-earth-stable' and 'google-chrome-stable'. It would also
prevent the possibility of that source offering a new package that
might accidentally get installed by 'typo' ( new package 'lib6c', hyuk
) or by an administrator who mistakenly sees a package show up
(aptitude search...) that looks useful, thinking it's part of the OS
distribution.
But, is this worthwhile -- does it actually protect you from something
that Apt wouldn't allow anyway?
lists# apt-cache policy libc6 | sed -e 's=\(https\{0,1\}\|ftp\):[^
]*=URI-REDACTED='
libc6:
Installed: 2.13-38+deb7u6
Candidate: 2.13-38+deb7u6
Version table:
*** 2.13-38+deb7u6 0
990 URI-REDACTED wheezy/main amd64 Packages
100 /var/lib/dpkg/status
2.13-38+deb7u4 0
990 URI-REDACTED wheezy/updates/main amd64 Packages
So, i don't have a 3rd party repo defined for libc6 (just site caching
repos). But what is to stop 'dl.google.com' from offering 2.15 of
libc6 and 'aptitude upgrade' installing it?
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator -
Re: Q: Best Practices for 3rd party APT sources for security considerations?
On Fri, Jan 23, 2015 at 6:42 AM, Stephen Dowdy wrote: SUMMARY: Q: Can a registered 3rd party repo spoof critical packages (e.g. libc6) and have them installed on apt 'upgrade' operations? Yes. Q: What are the best ways (configuration) to help manage 3rd party repos to constrain their capabilities? Setup a dpkg excludes configuration to prevent installation of cron jobs, systemd units, init scripts and so on. Setup some apt pinning to only allow certain packages from the 3rd-party repo. This may not work in the case of a malicious repository, one would have to do some testing first. If that doesn't work then you'll need new apt configuration options for this. Implement an option in apt/dpkg to disable maintainer scripts for repos that don't need them or shouldn't be trusted to have them. Is it possible for a 3rd party repository/source added in /etc/apt/sources.list.d/ to compromise a system by spoofing a new (higher) version of a critical package, such as 'libc6'? Yes, of course. The package name does not matter btw, any untrusted Debian package can compromise your system. Don't install untrusted software on your systems. Personally, right now I would do this: Create a new reprepro-based repository with the 3rd-party repository as an upstream that only pulls in whitelisted packages. Verify each update to the reprepro-based repository doesn't contain any issues you care about, modify the .deb files if so. You will need to check the install/upgrade/remove scripts in the .deb as well as any installed files for things like cron jobs, systemd units, init scripts and so on. Update your systems from the reprepro-based repository as per normal. -- bye, pabs https://wiki.debian.org/PaulWise -- 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/caktje6eb4t4y54mbn2nazss_uvukx2zbw2ajpq_a7n9ha7w...@mail.gmail.com
External check
CVE-2015-0238: RESERVED CVE-2015-0310: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yex72-0002bw...@soler.debian.org
Re: Is this a hacking attempt?
Bonno Bloksma b.blok...@tio.nl wrote: Van: paul.is.w...@gmail.com [mailto:paul.is.w...@gmail.com] Namens Paul Wise Fortunately, this works, but there are sites where doesn't. Do you have any examples of sites that still need Flash? Obviously flash game sites still need it but surely almost all of the web has moved away from it at this point? VMware based their new vSphere management interface around flash. The idea was that companies without Windows machines no longer need a Windows PC just to use the VMware client. All they need now is a machine with flash. ;-) Which has been subverted since vSphere 5.5, because Linux is no longer a supported platform for the vSphere Web Client. You can kind of limb along using Google Chrome, which has an included Flash 15 (Flash 11.5 or higher is needed for the vSphere Web Client whereas the last official Adobe release is 11.2) but then there are still features unavailable for Linux users, like beeing able to insert local CD/DVDs or images into the virtual DVD drive. Also the keyboard mapping for the virtual console is totally broken on Linux. If you configure your VM to use an English keyboard layout it kind of works, any other layout is unusable. For example you are not able to type the / while using a German keyboard layout. Any key using a modifier key like Alt or Shift (besides uppercase letters, which work) is broken. So in the end, you again need a Windows PC to use the vSphere Web Client if you need to use any feature besides VM powering on and off. Grüße, Sven. -- Sigmentation fault. Core dumped. -- 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/6batvoh82...@mids.svenhartge.de
