[HITB-Announce] REMINDER: #HITB2014KUL CFP Deadline: 1st August
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
Re: concrete steps for improving apt downloading security and privacy
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
Re: concrete steps for improving apt downloading security and privacy
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
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