gmane.linux.gentoo.security

Breakpoint 2012 Call For Papers

2012-05-10T11:48:16

                 . ______________________________________
                 ._\\.         Breakpoint 2012           (___.
                 :          Intercontinental Rialto          :
                 :           Melbourne,  Australia           :
                 :             October 17th-18th             :
                 :__                                    . ___:
                    )____________________________________\\
                                                            .
                          www.ruxconbreakpoint.com
                          www.twitter.com/ruxconbpx



Introduction
------------

 Breakpoint is a new security conference to be held on the 17th and 18th of
 October, in Melbourne Australia. The event will show case the work of expert
 security researchers from around the world on a wide range of topics.
 Breakpoint is organised by the Ruxcon conference team and will offer a
 specialised and more professional security conference to complement and lead
 into the larger and more casual Ruxcon weekend conference. Breakpoint will
 cater towards security researchers and industry professionals alike, with a
 focus on cutting edge security research.

 With just one day separating both conferences, Breakpoint presents a great
 opportunity for our selected speakers to receive a complimentary trip to
 Australia and experience both the Breakpoint and Ruxcon conferences, not to
 mention the great weather, awesome parties, and friendly people.

 Melbourne is Australia's cultural capital, with Victorian-era architecture,
 extensive shopping, museums, galleries, theatres, and large parks and gardens.
 It is a city of many subcultures, personalities and styles, and it is these
 layers that make it so interesting. Melbourne has a vibrant arts and music
 scene, eccentric cafes, cobbled lane-ways, quirky shops, intimate bars and
 restaurants, and is known as one of the world's great streetart capitals.


Important Dates
---------------

 * May     10        Call For Presentations Open
 * July    30        Call For Presentations Close
 * October 15-16     BreakPoint Training
 * October 17-18     BreakPoint Conference
 * October 20-21     Ruxcon Conference


Topic Scope
-----------

Topics of interest include, but are not limited to:


 o Mobile Device Security
 o Exploitation Techniques
 o Reverse Engineering
 o Vulnerability Discovery
 o Rootkit Development
 o Malware Analysis
 o Code Analysis
 o Virtualization, Hypervisor Security
 o Cloud Security
 o Embedded Device Security
 o Hardware Security
 o Telecommunications Security
 o Wireless Network Security
 o Web Application Security
 o Law Enforcement Activities
 o Forensics
 o Threat Intelligence
 o You get the idea


Submission Guidelines
---------------------

 In order for us to process your submission we will require the following
 information:


 1. Presentation title
 2. Detailed summary of your presentation material
 3. Name/Nickname
 4. Mobile phone number
 5. Brief personal biography
 6. Description of any demonstrations involved in the presentation
 7. Information on where the presentation material has or will be presented
    before Breakpoint

 * Preference will be given to presentations that contain original research
   that will be first presented at Breakpoint.
 * As a general guideline, BreakPoint presentations are between
   45 and 60 minutes, including question time.


 If you have any enquiries about submissions, or would like to make a
 submission, please send an email to bpx< at >ruxconbreakpoint.com


Speaker Benefits
----------------

 Speakers at BreakPoint will be entitled to the following benefits:                                                    

 - A round trip economy airfare to Melbourne (total cost limit applies)
 - Three nights accommodation at the Intercontinental Rialto
 - Complementary registration for Breakpoint and Ruxcon conferences
 - Invitation to all BreakPoint and Ruxcon parties
 - Unlock 'Presented on world's smallest continent' achievement

 * All speaker benefits apply to a single speaker per submission.


Contact
-------

 If you have any questions or queries, contact us at:

 * Email:            bpx< at >ruxconbreakpoint.com
 * Twitter           < at >ruxconbpx

Ruxcon 2012 Call For Papers

2012-04-19T05:04:06

Ruxcon 2012 Call For Papers

The Ruxcon team is pleased to announce the call for papers for the 2012 annual Ruxcon conference.

This year the conference will take place over the weekend of 20th and 21st of October at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of July.

* What is Ruxcon?

Ruxcon is the premier technical computer security conference in the Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information, please visit http://www.ruxcon.org.au

* Presentation Information

Presentations are set to run for 40 to 50 minutes, and will be of a formal nature, with slides and a speech.

* Topics

Topics of interest include, but are not limited to:

o Mobile Device Security
o Virtualization, Hypervisor, and Cloud Security
o Malware Analysis
o Reverse Engineering
o Exploitation Techniques
o Rootkit Development
o Code Analysis
o Forensics and Anti-Forensics
o Embedded Device Security
o Web Application Security
o Network Traffic Analysis
o Wireless Network Security
o Cryptography and Cryptanalysis
o Social Engineering
o Law Enforcement Activities
o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)

* Submissions

Submissions should thoroughly outline your desired presentation subject.

If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations< at >ruxcon.org.au

The deadline for submissions is the 15th of July.

If approved we will additionally require:

i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).

* Contacts

Email: presentations< at >ruxcon.org.au
Twitter: ruxcon

(unknown)

qubin — 2011-12-09T06:21:59

Re: CVE-2011-4313 - BIND 9 Resolver crashes after logging an error in query.c

Matt Thode — 2011-11-17T08:48:23

On Nov 17, 2011, at 1:30 AM, David Sommerseth wrote:


https://bugs.gentoo.org/show_bug.cgi?id=390753

CVE-2011-4313 - BIND 9 Resolver crashes after logging an error in query.c

David Sommerseth — 2011-11-17T07:30:03

Hi,

This is a very fresh CVE, and I wondered if this has caught your attention?
 When would it be reasonable to expect an update for this issue?  ISC have
already released patches fixing this issue.

https://www.isc.org/software/bind/advisories/cve-2011-4313


kind regards,

David Sommerseth

Re: No GLSA since January?!?

Tobias Heinlein — 2011-08-27T13:34:27

Rich Freeman wrote, on 08/27/2011 03:06 PM:

Yes, we are aware of that. We know it's very unfortunate, but just
*stating* it doesn't get us more manpower.


We currently believe the tool *is* just a few weeks away; we plan to
meet in person at the end of September. But I don't want to promise
anything as real life may get in the way anytime.


Sure, but that is not the case. It's still possible to use the old
GLSAmaker and send out advisories; the problem is manpower. No-one
currently wants to do the work with the old tool (And no, editing XML
files manually won't motivate people either).


That's similar to the bug wrangling situation a while ago. The queue was
huge and everyone knew we needed more people to wrangle the bugs. But
how many people actually did that for more than a few? Not even a handful.

Having maintainers "care" about security just won't work out. That's why
the security team exists in the first place.

Re: No GLSA since January?!?

Rich Freeman — 2011-08-27T13:06:43

So, if we weren't able to log or update any bugs for six months, we
would probably at least give devs a spreadsheet on google docs or
something.  I wouldn't suggest that we put the distro on hold until
somebody could re-engineer bugzilla.

If we had an automatic ebuild creator and nobody created ebuilds for
six months I'd suggest that we create them by hand.

We're talking about emails and xml files - neither of which are
terribly complex.  Exact format on the former is not critical, and the
syntax of the latter can be checked with standard tools.  If on rare
occasion we get one wrong we fix it - just like we do with ebuilds
(the libpng glsa still shows stable amd64 as vulnerable, so simply
having a tool doesn't prevent mistakes).


I have no doubt that automation is better than no automation.
However, that isn't really what we're discussing here.  What we're
talking about is GLSAs vs no GLSAs.  Working automated GLSAs
apparently don't exist right now.  It is wonderful that a bunch of
people are looking to change that, however it doesn't really change
the fact that we're not sending out GLSAs, and that makes it hard for
people to take Gentoo seriously as a distro.  If the new tool were
just a few weeks away then a few posts to -dev/-security updating
status would probably alleviate concerns.  However, I think that
people have been talking about fixing the GLSA tool for ages now.

I think the fundamental problem is failing to distinguish between
operations and improvements.  You can't put the former on hold to work
on the latter.  It seems like we're trying to debate how to build the
Hagia Sophia while we're sleeping on dirt and rocks.  In my thinking
the most critical requirement is that we send out a notice when we
have a vulnerability, and describe what the vulnerability is (in a
sentence with links), and what versions are and are not vulnerable.
When resource constraints hit a volunteer project, the solution is
usually to create a more distributed solution.

Rich

Re: No GLSA since January?!?

Tobias Heinlein — 2011-08-27T12:34:39

Rich Freeman wrote, on 08/27/2011 02:13 PM:

I have read that idea multiple times now, each of them by people not on
the security team or something similar. It just doesn't work that way.
It's like suggesting to ditch Bugzilla and instead enter bugs manually
with SQL commands into a database. Well, not quite, but you get the idea.

Also, as previously stated, we know that the tool sucks, which is why
Alex has been working for months on new tools. We really wouldn't spend
that much time on that if it wasn't worth it.

Re: No GLSA since January?!?

Rich Freeman — 2011-08-27T12:13:02

The current GLSA mechanism already provides both of these.  There are
the email notifications, and there is an xml file that provides the
masking information (which the glsa-checker tool and some package
managers use).

From what I've seen (from a distance), the problem seems to be that
both of these are created using a software tool which is apparently
very cumbersome to use.  However, both are just text files.

Part of me wonders if a workflow like this would help solve the problem:

1.  Some contributor posts a GLSA email and xml file to a security
bug.  This could be anybody.  The content would be trimmed down a bit
- perhaps just a CVE reference, and then the information on vulnerable
and non-vulnerable versions.

2.  Somebody on staff with commit access to the xml tree and the
mailing list would review and send out the advisory, and mark this as
done in the bug.

I also wonder if there would be in value in sending out the notice
after the fixed version is in the tree but before it is stable.  Right
now advisories wait until the last security-supported arch stabilizes
the package.  I would think that earlier notice would be useful - even
if sysadmins want to wait for a package to become stable they'll know
something is coming, and the delay on the major arches tends to be
hours to days.  Plus, if somebody can't wait they can test/install on
their own, and perhaps even post feedback on the bug.

Obviously notices would have to wait until after any blackout period ends.

Note that I'm basically advocating ditching the tool.  A tool is good
when it improves productivity.  However, right now it appears that the
tool is keeping people from contributing who want to contribute.
Certainly things couldn't get worse without the tool.  If a user just
edits an xml template and email template and posts it on the bug, then
very little work should be required to review the files before posting
them.  Contributors wouldn't need any special access either - freeing
up devs to provide more of a QA role.

Ditching the tool would also simplify fixes to GLSAs.  I haven't run
it in a while, but took glsa-checker out of my cron ages ago when it
would just report packages with vulnerabilities that had none.  I did
log bugs, but apparently adding one line to the xml files requires as
much pain as sending out the original notice.

Bottom line, however, is I don't think that we can't consider
ourselves as a serious distro if we don't provide timely security
advisories.

All that said, I would say that from what I've seen in bugzilla, if
you're on x86 or amd64 and running an updated stable tree, you
shouldn't have longstanding security vulnerabilities.  A new security
bug pops up almost weekly, and packages are updated fairly quickly on
those arches.  The problem is just that we never tell anybody that
we're doing it.

Rich

Re: No GLSA since January?!?

Christian Kauhaus — 2011-08-27T08:49:09

Am 26.08.2011 20:08, schrieb Kevin Bryan:

Your idea sounds interesting and could lead to very cool technology like the 
'ACCEPT_RISKS="..."' variable mentioned elsewhere in this thread.

But it does not solve a major part of the use case. In my opinion, we need to 
get notifications about security risks over an independent channel without 
having to update the portage tree.

For me (and the rest of my company) the greatest advantage of Gentoo over 
other distributions it it's "continuous integration" approach. Updates get 
committed to the portage tree continuously over time and administrators are 
completely free on how often and when they update their systems. This is 
great. But given I have an installed base and I have no reason to update the 
portage tree now, I need a reliable information about "this package is 
borked". Then I should go for update as fast as possible of course. :-)

So in consequence I would appreciate to have both mechanisms: a timely 
up-front notification via GLSAs (probably more brief than the past ones) and 
some sort of security masking.

Regards

Christian

Re: No GLSA since January?!?

Daniel A. Avelino — 2011-08-26T23:38:50

But Alex, this could be a great improvement in system at all. This can
help administrators to measure better its systems, and may be "force"
developers to solve issues faster.

What do you think?


Daniel

On 8/26/11, Alex Legler <a3li< at >gentoo.org> wrote:

Re: No GLSA since January?!?

Alex Legler — 2011-08-26T22:27:33

I see this as an addition to sending advisories after fixing an issue, not as 
a solution to the issue at hand.

Re: No GLSA since January?!?

Daniel A. Avelino — 2011-08-26T20:40:49

I like this approach but I have no idea about how this could be performed.

ACCEPT_RISKS="remote dos"  emerge ...

Sounds very cool to me.

Daniel

On 8/26/11, Kevin Bryan <bryank< at >cs.uri.edu> wrote:

Re: No GLSA since January?!?

Kevin Bryan — 2011-08-26T20:02:56

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was not considering the entire process, just the part that really
impacts me: identifying vulnerable and patched packages.  Full
advisories are nice, but really what I want to know is when I need to
update a particular package.

You are right that marking the packages that contain fixes doesn't
really scale because of increased baggage to carry forward.

The problem I have with GLSA's is that they don't come out until after
the problem has been fixed.  

Perhaps it would be better to just have a system to label a particular
ebuild/version as vulnerable.  Maybe something closer to package.mask,
but for security would be appropriate.  With a package.security_mask,
you could have anyone on the security project update that file with
packages as soon as they know about it and while they are waiting on the
devs to fix it.  References/links/impact could be noted in the comments
above, as package.mask does now.

As for interacting with 'emerge', I don't think we want the same
semantics as package.mask, since we don't want to force a downgrade (if
possible).  It should probably just warn when you ask it to install a
vulnerable version.  Upgrades to safe versions will be quiet that way.
The < at >security would contain packages with and without fixes so you get
warnings for things that remain vulnerable, and updates for things that
are fixed.

Thoughts?

- --Kevin

On Fri, Aug 26, 2011 at 08:40:29PM +0200, Alex Legler wrote:


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5X+/AACgkQ6ENyPMTUmzrujACfUhO6S0CUQ6RaX+Q+IAZM69Wd
VakAnA4yzElckmCZaikTsPZdWZU5VazF
=MSwi
-----END PGP SIGNATURE-----

Re: No GLSA since January?!?

Joost Roeleveld — 2011-08-26T19:30:02

Alex,

If my reply seemed, in any way, to suggest I do not appreciate the amount of 
work that has been going into the GLSAs and the difficulty in finding the 
people to keep doing it, then I am sorry.
It wasn't meant to sound that way.

I'll go read the Padawan page and see if there is anything I can do.

For others, the padawan-page can be found here:
http://www.gentoo.org/security/en/padawans.xml

--
Joost

Re: No GLSA since January?!?

Daniel A. Avelino — 2011-08-26T19:27:03

Alex.

For WEB vulnerability discovering, one of the most important to us is Nessus
to
search and confronting against CVE database. Sometimes, Nessus find some
vulnerable packages in our Gentoo boxes and when we go to emerge -UDN this,
there is not the updated version even when the fixes are available [in other
distros
for example].

The Core Impact

http://www.coresecurity.com/

do a great job too but we only tested the demo version. [That is great too].

There is other interesting tool [not really WEB related but...] the Secunia
PSI

http://secunia.com/vulnerability_scanning/online/

that do a great job in search unupdated packages but Windows only.

Reading your last answer, I had the impression we are talking about
different things but I think
I can connect them. My apologies to speculate without read the complete team
work documentation
but even if issue correction is not our job as you said, I think we could
pressure package maintainers
to update its packages since we (in thesis) have more visibility about
packages vulnerabilities that can be fixed but
aren't fixed yet. This could be impact even in GLSA's update for example.

So, if we have a automatic mechanism that searchs into vulnerabilities
databases - CVE - for example and find what
packages have issues that was already fixed, we could, for example, label
packages
with some flag that tells users and developers that this package needs
review to fix some vulnerability.

I thought this is an interesting point to discuss because this could in
principle force updates to be more
fast and more Bugzilla-free. I have nothing against Bugzilla but the process
as a whole takes too much time
and we could in principle search vulnerabilities databases and provide
developers and users with informations
about how their systems security are.

Thanks again.

Daniel

On Fri, Aug 26, 2011 at 3:44 PM, Alex Legler <a3li< at >gentoo.org> wrote:

Re: No GLSA since January?!?

Alex Legler — 2011-08-26T18:44:06

We already use CVE as one of our sources of vulnerability intelligence. 
Finding issues is also not the real issue here.
Also, actual issue correction is not our job, it's the responsibility of the 
package maintainer.

Can you share details about the utilities you are using?

Alex

Re: No GLSA since January?!?

Daniel A. Avelino — 2011-08-26T18:41:58

Hi Kevin.

That is an interesting idea. So one could check about vulnerabilies
solutions
_before_ package installation. And better. This could give us a measure
about
how secure [think a little bit ahead] packages in portage tree are.

Actually, there are some mechanisms to know what is the mean time
corrections are
provided when one look to portage's tree as a whole?

I like this idea and would like to suggest two other variables

SECURITY_CORRECTION_DATE
SECURITY_DISCOVERY_DATE

containing the date the correction was published on portage tree and
the date the problem was post [may be in bugzilla]

Let me go back and continue to read Security Project documentation.


Regards,

Daniel A. Avelino


On Fri, Aug 26, 2011 at 3:08 PM, Kevin Bryan <bryank< at >cs.uri.edu> wrote:

Re: No GLSA since January?!?

Alex Legler — 2011-08-26T18:40:29

A complete change of the system is very unlikely.
Nevertheless: What is the end-to-end process in your solution? (i.e. 
vulnerability report to 'advisory' release)

A while ago a similar solution was proposed. Basically you want to shift our 
job back to the package maintainers. That might work, but rais a few new 
issues.

We'd automatically lose some consistency, because not everyone would follow 
the needed or wanted data scheme. Such a thing is much better to control in a 
smaller and better connected group of people.

Also, cleanup and large amounts of issues in packages are issues. Browsers 
usually get hundreds of CVEs assigned in a year, that would be all in the 
Ebuild, and for how long?

Personally, I'm not convinced this is a model that would be an improvement 
over the current situation.

Alex

Re: No GLSA since January?!?

Daniel A. Avelino — 2011-08-26T18:22:40



developers to find
vulnerabilities in a more fast way [searching and confronting CVE, for
example] and  start a
"call for solution" process. I work with solutions of this type for WEB
vulnerabilities discover
and some tools are very interesting to reduce the correction time.

By the way, I will start to read about what a Padawan should know instead of

make speculations prematurelly. :D

Thank you very much for the explanations.

Daniel A. Avelino

Re: No GLSA since January?!?

Kevin Bryan — 2011-08-26T18:08:38

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Although I like having the summary information about what the
vulnerability is, if I'm only reading them for packages I have
installed, then a reference of some kind would suffice.

I'd be fine even if it was just a new variable in the .ebuild file that
somehow indicated which versions it was a fix for, reusing the syntax
for dependency checking.  A reference to the CVE or gentoo bug reference
would be good, too:

SECURITY_FIXES="<www-plugins/adobe-flash-10.1.102.64"
SECURITY_REF="CVE:2010-2169 http://..."
SECURITY_BUG="343089"
SECURITY_IMPACT="remote"

Then would be most of the work the committer needs to do is right there
in a file they are modifying anyway.

The portage < at >security set could also look for and evaluate these tags,
instead of parsing the GLSA's.

Note on the impact variable: make a few easy to understand tags:
local
remote
remote-user-assist
denial-of-service
...

- --Kevin


On Fri, Aug 26, 2011 at 07:06:35PM +0200, Christian Kauhaus wrote:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk5X4SYACgkQ6ENyPMTUmzpTLwCeIrikkC82ZC/YMALUD3AUOG71
GQ0An02FoagrOJSU4kFQ8RUP+q/1+zQn
=/kf5
-----END PGP SIGNATURE-----