Re: concrete steps for improving apt downloading security and privacy

2014-07-16 Thread Michael Stone

On Wed, Jul 16, 2014 at 01:45:36AM +0200, Holger Levsen wrote:

AIUI Hans-Christoph wants something else _also_, not instead. And technically
I think those signed .debs even exist already, via hashes in signed .changes
files. Or am I getting something wrong?


Yes you are--what you described is exactly how the Release files work.

Mike Stone


--
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/2d6a9800-0cd3-11e4-a8ca-00163eeb5...@msgid.mathom.us



Re: concrete steps for improving apt downloading security and privacy

2014-07-16 Thread Holger Levsen
Hi,

On Mittwoch, 16. Juli 2014, Michael Stone wrote:
 Yes you are--what you described is exactly how the Release files work.

Well, there are (many) other .debs on the net which are not part of our 
releases, so it still seems to me that making .changes files accessable in 
standardized ways could be very useful.


cheers,
Holger




signature.asc
Description: This is a digitally signed message part.


Re: concrete steps for improving apt downloading security and privacy

2014-07-16 Thread Hans-Christoph Steiner


On 07/16/2014 08:06 AM, Holger Levsen wrote:
 Hi,
 
 On Mittwoch, 16. Juli 2014, Michael Stone wrote:
 Yes you are--what you described is exactly how the Release files work.
 
 Well, there are (many) other .debs on the net which are not part of our 
 releases, so it still seems to me that making .changes files accessable in 
 standardized ways could be very useful.

What I'm talking about already exists in Debian, but is rarely used.  dpkg-sig
creates a signature that is embedded in the .deb file.  So that means no
matter how the .deb file got onto a system, that signature can be verified.
I'm proposing to start making dpkg-sig a standard part of official .deb files.
 This can be done in stages to make it manageable.  Here's a rough idea of that:

1. Adding a 'builder' signature should be easy to start with, make `debsign`
also run `dpkg-sig --sign builder` on any .deb files it finds.  I believe that
`dpkg -i` will already try to verify a signature if it exists.

2. add something like `dpkg --require-debsig` to force checking of the
dpkg-sig signature.  This would be optional to start with, and complimentary
to the already existing `dpkg --no-debsig`.

3. make `dpkg-buildpackage` call `dpkg-sig --sign builder --sign-changes full`
to sign packages.

4. etc.

As for Michael's complaint that I have not described a real problem, I have
tried already in the thread, so I'll try again in bullet points:

* TAILS is a Debian-based live CD
* the core system image by definition cannot be modified (live CD)
* it has a feature for persistent storage of files on a USB thumb drive
* it also can save apt cache/lib to that persistent store
* it will automatically install packages on boot from that store
* mostly people use TAILS in online mode
* there is a fully offline mode in development
* offline TAILS cannot verify the packages if apt lists are  2 weeks
* updating the apt cache/lib is painful on an offline machine
* an offline machine's threat model is drastically simpler

On top of all that, each update increases risk of compromise on offline
machines because each new update provides a vector to run a script or
introduce new code that otherwise does not exist (no network!).  And any
decent attacker with physical access to the machine will always get in.

Other people want to be able to directly download .deb packages and have then
verified as part of the install process.  This is not my primary concern, but
I do think it is a valid one.  It would also be addressed by fully support of
dpkg-sig.

.hc



signature.asc
Description: OpenPGP digital signature


[HITB-Announce] REMINDER: #HITB2014KUL CFP Deadline: 1st August

2014-07-16 Thread Hafez Kamal

The deadline to submit your papers for the LAST AND FINAL HITB
Security Conference in Malaysia is just around the corner!

HITBSecConf2014 - Malaysia takes place at Intercontinental Kuala Lumpur
from October 13th - 16th (13th / 14th = training // 15th / 16th =
conference)

http://conference.hitb.org/hitbsecconf2014kul/

We're looking for talks that are highly technical, but most
importantly, material which is new, fresh and that _hasn't been
presented previously_ Here are a few talks that have already been
accepted for inclusion into the conference:

ARM Wrestling a Printer: How to Mod Firmware
http://conference.hitb.org/hitbsecconf2014kul/sessions/arm-wrestling-a-printer-how-to-mod-firmware/

Abusing JSONP with Rosetta Flash
http://conference.hitb.org/hitbsecconf2014kul/sessions/abusing-jsonp-with-rosetta-flash/

Browser Fuzzing in 2014: Where to Throw Your Stones
http://conference.hitb.org/hitbsecconf2014kul/sessions/browser-fuzzing-in-2014-david-vs-goliath-a-k-a-learn-where-to-throw-your-stones/

---

HITB CFP: http://cfp.hackinthebox.org/

Each accepted submission will entitle the speaker(s) to
accommodation for 3 nights / 4 days at the InterContinental Kuala Lumpur
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 (3000
- 5000 words).

Your submissions will be reviewed by The HITB CFP Review Committee:

Charlie Miller, Twitter
Katie Moussouris, Chief Policy Officer, HackerOne
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
Dr. Marco Balduzzi, Senior Researcher, Trend Micro
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

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/ri2nu0c-fwik-4m4x-le7f-wt8lirewa...@hackinthebox.org



External check

2014-07-16 Thread Raphael Geissert
CVE-2014-2483: RESERVED
CVE-2014-3518: RESERVED
CVE-2014-3530: RESERVED
CVE-2014-4208: RESERVED
CVE-2014-4220: RESERVED
CVE-2014-4221: RESERVED
CVE-2014-4223: RESERVED
CVE-2014-4227: RESERVED
CVE-2014-4247: RESERVED
CVE-2014-4264: RESERVED
CVE-2014-4265: 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/53c61f34.bqygdikbngv0aord%atomo64+st...@gmail.com