Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
dailydave-requ...@lists.immunitysec.com
You can reach the person managing the list at
dailydave-ow...@lists.immunitysec.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Re: Exploits matter. (Alexander Sotirov)
2. Re: Exploits matter. (Aaron)
3. Re: Exploits matter. (alexm)
4. Re: Exploits matter. (vincent hinderer)
5. Re: Exploits matter. (security curmudgeon)
6. Re: Exploits matter. (security curmudgeon)
----------------------------------------------------------------------
Message: 1
Date: Thu, 8 Oct 2009 12:11:42 -0400
From: Alexander Sotirov <a...@sotirov.net>
Subject: Re: [Dailydave] Exploits matter.
To: Ilfak Guilfanov <i...@hexblog.com>
Cc: dailydave@lists.immunitysec.com
Message-ID: <20091008161142.ga3...@macbook-2.local>
Content-Type: text/plain; charset="iso-8859-1"
On Thu, Oct 08, 2009 at 10:47:19AM +0200, Ilfak Guilfanov wrote:
> Sorry for my ignorance, are NULL pointer dereference bugs exploitable today?
Hi Ilfak,
NULL pointer dereferences in userspace programs are generally not exploitable,
but in some rare cases they might be. For example, Mark Dowd published a Flash
exploit where a NULL pointer was used as the base of an array that was accessed
with an arbitrary array index. This turned the NULL pointer dereference into an
arbitrary memory write operation. Here's his detailed writeup about the exploit:
http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf
This exploitation technique (and other interesting ones) were also described
in a really under-appreciated presentation by Ga?l Delalleau at CanSecWest 2005:
http://cansecwest.com/core05/memory_vulns_delalleau.pdf
In the Linux kernel, NULL pointer dereferences are exploitable in many cases,
because the user can mmap memory at address 0 through a variety of techniques
and take control of the data structure the kernel is dereferencing. Brad
Spender has released multiple Linux local privilege escalation exploits
to prove this point. See this blog post for more info:
http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html
Take care,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url :
http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/7371e7c2/attachment-0001.pgp
------------------------------
Message: 2
Date: Thu, 8 Oct 2009 10:19:12 -0700 (PDT)
From: Aaron <apcon...@yahoo.com>
Subject: Re: [Dailydave] Exploits matter.
To: Ilfak Guilfanov <i...@hexblog.com>
Cc: dailydave@lists.immunitysec.com
Message-ID: <771076.56612...@web65403.mail.ac4.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
Under linux, it's as easy as setting your "personality" to SYSVR4, mmap'ing the
0th address, and filling it with your code.
That's for local exploit anyway. I'm not sure about remotely exploiting a NULL
dereference, or about non-linux systems (read: it may be possible, but I just
don't know for sure one way or the other).
________________________________
From: Ilfak Guilfanov <i...@hexblog.com>
To: Steve Shockley <steve.shock...@shockley.net>
Cc: dailydave@lists.immunitysec.com
Sent: Thu, October 8, 2009 4:47:19 AM
Subject: Re: [Dailydave] Exploits matter.
Sorry for my ignorance, are NULL pointer dereference bugs exploitable today?
Steve Shockley said the following on 7/10/2009 15:56:
> On 10/6/2009 10:12 AM, dave wrote:
>> But if you are like me, you are thinking "But it's still worth it". And
>> here's why: Without exploits, you have no way to know what matters. Or,
>> more realistically, what doesn't matter. I.E. in this case, 64 bit
>> computers are not going to be exploited with SMBv2 any time soon, of at
>> all. Since enterprises skipped Vista and use 64 bit for their Windows
>> 2008 servers, SMBv2 didn't hurt as badly as you would expect.
>
> Doesn't that just mean that *you* can't exploit it right now? Not
> trying to insult your haxxor skillz, but a few years ago you couldn't
> get a virus via email or Word, and null pointer dereference bugs could
> never be exploited.
> _______________________________________________
> Dailydave mailing list
> Dailydave@lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
--
Best regards,
Ilfak mailto:i...@hexblog.com
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/ab7dc86a/attachment-0001.htm
------------------------------
Message: 3
Date: Thu, 08 Oct 2009 15:11:43 -0400
From: alexm <al...@immunityinc.com>
Subject: Re: [Dailydave] Exploits matter.
To: dailyd...@lists.immunityinc.com
Message-ID: <4ace396f.50...@immunityinc.com>
Content-Type: text/plain; charset=ISO-8859-1
Tom Parker wrote:
>> It would indeed be a good thing if Immunity et al would publish some kind of
>> unified database of their proprietary exploits, mapped to CVE-ID etc, but
>> I'm not sure if it's their responsibility to do so. IMO, the scanning
>> vendors, Qualys, Rapid7, nCircle etc are missing a trick if they aren't
>> buying themselves a copy of CANVAS and ensuring that when their scanner
>> finds a vulnerability supported by it [CANVAS], they are providing users a
>> CVSS score based on the fact that they have independently verified the
>> existence of robust exploit code for the respective vuln
>>
Most of our exploits are mapped to their respective CVE numbers, many
months ago we made an internal push to get everything much more uniform
within the documentation dicts of exploit modules. We include CVE
Number, CVE URL and since we do a lot of Microsoft bugs the MS security
number as appropriate. With some of our 3rd party vendors who deal in
0day obviously CVE numbers are not available and sometimes exploits will
be developed against bugs that are silently patched, so it's not a
perfect system.
We had a lot of customer requests for being able to import results from
some vulnerability scanning tools. Looking at the formats for those
files we realized that all the major scanning tools had an option to
report vulnerabilities as their CVE number. So the way this specific
part of the code works is that once hosts and CVEs are parsed out of the
report, those CVE numbers which have corresponding CANVAS modules are
kept and attributed to the host while those that do not have modules are
dumped.
One of the primary usage cases we see for CANVAS works like this:
1) Use vulnerability scanning product X over network segment
2) X returns a list of potential vulnerabilities against the hosts on
that segment
3) Start CANVAS, import list, run the appropriate modules against the
imported hosts
So while it's not our responsibility as such to maintain this reference
between exploit modules and CVEs I think it's in our best interests to
do so and we've got a pretty strong case from our customers to make it
happen. I'm sure the other products/projects in this space do similar
things.
Cheers,
-AlexM
------------------------------
Message: 4
Date: Thu, 08 Oct 2009 22:30:58 +0200
From: vincent hinderer <vhinde...@lexsi.com>
Subject: Re: [Dailydave] Exploits matter.
To: Tom Parker <t...@rooted.net>, security curmudgeon
<jeri...@attrition.org>
Cc: dailyd...@lists.immunityinc.com, dave <d...@immunityinc.com>
Message-ID: <c6f418a2.66a75%vhinde...@lexsi.com>
Content-Type: text/plain; charset="us-ascii"
>>
>
> While I understand the challenge of verifying the existence and nature of
> commercial exploitation tools, down playing exploits by databases like OSVDB
> is damaging to the industry and is creating a false sense of security amongst
> organizations - especially those who charge their security programs to vanilla
> CISSP's. Case in point - large company runs an automated scanner over their
> network on a monthly basis, which regularly finds flaws. They prioritize
> remediation of findings based on CVSS scores, which have been calculated in
> part through utilizing data from OSVDB. Days, months, weeks later the
> organization is attacked/audited by a group who paid/stole/borrowed a copy of
> Canvas/Core/et al. Organization gets owned.
>
> I agree. Working these days on patching a 2003 (!) flaw...
>
> The past two VzB data breach reports have demonstrated a trend, that a large
> number of compromises (around 70% if memory serves), resulted from
> exploitation of vulnerabilities that at time of compromise had been patched by
> the vendor for a year or more. I'm not sure how you would go about obtaining
> this kind of data (or indeed how VzB gets their data), but it would be an
> interesting metric to see how many of those known/vendor-patched issues had
> been neglected/de-prioritized due to misconceptions about their level of
> exploitability.
>
In Verizon report :
patch availability at time of attack
-between 0,5 to 1 year = 1
-for more than 1 year = 5 (83%)
Total of attacks = 6
A relatively small set to draw conclusions though...
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20091008/75dd51fe/attachment.htm
------------------------------
Message: 5
Date: Thu, 8 Oct 2009 21:53:05 +0000 (UTC)
From: security curmudgeon <jeri...@attrition.org>
Subject: Re: [Dailydave] Exploits matter.
To: Wouter Slegers <wou...@yourcreativesolutions.nl>
Cc: dailyd...@lists.immunityinc.com
Message-ID: <pine.lnx.4.64.0910082135000.8...@forced.attrition.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
: > The difference betwene $US 30 and $US 200 is big. The difference between $US
: > 30,000 and $200 is even bigger. I mention that because I believe your . in
: > the 30.000 value really means 30,000, which is a huge difference to us
: > Americans. Regardless of your use of . vs , anyone versed in math or
: > economics could lecture on percentages of 30 and 200, or 200 and 30000.
: There is no need to flame bate, I only inserted the dots (yes, European style,
I apologize, it was not my intention to be flame bait. I just wanted to
make the distinction that trying to track value, while very intersting, is
definitely outside the scope of what a VDB can realistically track.
: > As applies to OSVDB, if I am doubting our ability to intellectually track
: > "public vs private", then the debate over the dollar value should not be
: > very relevant, especially in a historic context.
: So if I understand you correctly, for you "public versus private" is
: more useful in the decision whether to worry about some rumored attack
: then the difficulty for a given attacker? Or to ask it differently, I
: would worry based on the cost to one attacker (i.e. under the assumption
: that there is always one), not on the amount of attackers, whereas you
: seem to worry about the amount of attackers (based on their access to
: the attack)?
OSVDB wants to track public vs private (and likely a more granular
metric), unrelated to someone using us as a source on 'should we worry?'.
I certainly hope no one uses us as a definitive source on the status of an
exploit other than a link we may provide to it. We also have no intention
of tracking the amount of attackers, be it companies like Immunity or Core
or trying to determine how many bad guys may be out there that developed
it.
: > In the last few years, we have also begun to discuss and implement a
: > framework for tracking *vendor confidence*. It isn't only researchers that
: > are flaky and ill-equipped to handle vulnerability disclosure. =)
: Interesting, I did not know it was already so far in software
: vulnerability domain. So in essence there is already for a long time a
: mechanism to describe "claimed to be privately available" in the
: vulnerability databases (and apparently from your heated reaction, this
: was hard won. Kudos!). That means Dave's original question still holds:
It was, and its still in its infancy. Despite that, every VDB uses their
own form of resarcher confidence. Unfortunately, most (including OSVDB)
can only do it based on personal history of working on a VDB. Our goal is
to actually define that confidence level, show our 'math' and publish it.
The knowledge I have of vulnerability disclosure as pertains to the
researchers and their reliability should not die with me. Anyone should be
able to look at that history should they need it (e.g., hiring purposes,
risk assessment).
: why is it then so important that it is public (i.e. for free for all) or
: commercially available for $4000 from a reputable vendor to anyone that
: can pay that amount? I mean a free public exploit is more likely to
I don't think it is that important, it's an interesting metric to track.
We run into this often; we think "it would be neat to track X" then debate
it to death, determining if it is valuable to users, relevant to the
database or will end up having more issues and uncertainty than value.
: I can imagine that that is because of the different views.
: The researchers see their confidence scores as selling point, a higher score
: means more importance hence more market value (in money, prestige, Kudos,
: whatever). The good ones also want something to clearly distinguish them from
: the wannabes with good marketing.
True, but it can bite someone in the ass too. If they publish 100
vulnerabilities and 20% end up being incorrect, that could later haunt
them if they try to work for a company doing vulnerability research.
: > overhaul to our classification system regarding exploit availability, as
: > well as "vulnerability framework" vendors, free and commercial, to share
: > with us a better understanding of what they have in their arsenal without
: > giving away details that are a detriment to their commercial advantage.
: Interesting. So the market isn't picking up on it but it is not clear yet why.
: Your proposal later on looks like a serious step towards it.
I think it is obvious personally. If I say there is a remote overflow in
product X, that is all it really takes for a skilled researcher to start
dissecting the software and figure it out. There has to be a serious
balance in what you advertise you have as far as 0-day, or you run the
risk of giving away too much and devaluing your product. Immunity
advertises the exploits they have for published vulnerabilities because it
gives nothing away. If they say "we have a remote for apache" that is
vague. If they say "we have a remote for apache related to header
handling", that likely significantly reduces the time required for a third
party to find the issue.
: Good point. I think this (and my confusion about why it matters) comes down to
: different levels of assurance one is seeking. I recently (at the CC conference
: 2 weeks ago) sat in a panel next to Oracle and Microsoft as the "big software
: companies", informally representing the smartcard community. I was struck at
: the different realities the two domains have and this seems to apply here
: also.
:
: In the general software domain, the products are so huge that there is
: inevitably huge amounts of bugs in there and have essentially next to no
: defense in depth so in many cases it is exploitable also. So there your
: timeline point is valid, i.e. the time between possibility to patch (with a
: need to patch, maybe here is the public/private discussion?) and the
: weaponized exploits is the window of opportunity. So anything that reduces
: this (silently patching by the vendor, quickly patching, pressuring to
: avoid/delay disclosure, etc) is useful. Your proposal would create very
: interesting measurements on timing especially.
Absolutely. Unfortunately, due to time and lack of information, it could
likely only be done with the big vulnerabilities; the Microsoft, Oracle
and Cisco remotes. The 'lesser' vulnerabilities, even if being widely
exploited (e.g., SQLi), don't come with enough information to do that
analysis I bet.
: Interesting discussion, thank you!
Very =)
------------------------------
Message: 6
Date: Thu, 8 Oct 2009 22:07:34 +0000 (UTC)
From: security curmudgeon <jeri...@attrition.org>
Subject: Re: [Dailydave] Exploits matter.
To: Tom Parker <t...@rooted.net>
Cc: dailyd...@lists.immunityinc.com
Message-ID: <pine.lnx.4.64.0910082159190.8...@forced.attrition.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 8 Oct 2009, Tom Parker wrote:
: > Ten thousand or not, I cannot download the exploit from Immunity's web
: > site, milw0rm or anywhere else, correct? To me, and to OSVDB who tracks
: > that metric, that is flagged as 'rumored/private'.
:
: > Can our industry really put a numeric line on public vs private in the
: > scenario you describe? Do 9,999 CANVAS customers = private, but 10,000
: > CANAVAS customers = public?
:
: While I understand the challenge of verifying the existence and nature
: of commercial exploitation tools, down playing exploits by databases
: like OSVDB is damaging to the industry and is creating a false sense of
How exactly does OSVDB 'downplay' exploits using the current
classification system? We're the only VDB to even say "an exploit likely
exists, even though not public" which should be the opposite of
downplaying.
If you have a good answer to that, how can we improve the classification
system to more accurately track such metrics, without causing a problem?
: security amongst organizations - especially those who charge their
: security programs to vanilla CISSP's. Case in point - large company runs
: an automated scanner over their network on a monthly basis, which
: regularly finds flaws. They prioritize remediation of findings based on
: CVSS scores, which have been calculated in part through utilizing data
: from OSVDB. Days, months, weeks later the organization is
: attacked/audited by a group who paid/stole/borrowed a copy of
: Canvas/Core/et al. Organization gets owned.
First, we display CVSS scores as calculated by NVD if there is a CVE
assignment. We will calculate our own scores if we a) disagree or b) have
an entry w/o a CVE.
Either way, I don't quite follow the logic above, as applies to how OSVDB
(or any VDB) is doing wrong or contributing to the problem.
: The past two VzB data breach reports have demonstrated a trend, that a
: large number of compromises (around 70% if memory serves), resulted from
: exploitation of vulnerabilities that at time of compromise had been
: patched by the vendor for a year or more. I'm not sure how you would go
: about obtaining this kind of data (or indeed how VzB gets their data),
They get their data from their own clients, based on forensic examination
post-compromise.
: but it would be an interesting metric to see how many of those
: known/vendor-patched issues had been neglected/de-prioritized due to
: misconceptions about their level of exploitability.
That would be a really neat addition to the report next year.
: It would indeed be a good thing if Immunity et al would publish some
: kind of unified database of their proprietary exploits, mapped to CVE-ID
: etc, but I'm not sure if it's their responsibility to do so. IMO, the
I'd love for them to use CVE or another VDB to do just that. They have
absolutely zero responsibility to do it, and it has a bigger chance of
hurting them than helping them (see my previous post about disclosing your
0-day).
: scanning vendors, Qualys, Rapid7, nCircle etc are missing a trick if
: they aren't buying themselves a copy of CANVAS and ensuring that when
: their scanner finds a vulnerability supported by it [CANVAS], they are
: providing users a CVSS score based on the fact that they have
: independently verified the existence of robust exploit code for the
: respective vuln.
I believe many of these products have licenses that prevent reverse
engineering. If a company like the ones you mention above were to obtain
a copy, they would be violating the licensing and possibly the law. If a
scanner had a consistent pattern of adding checks that mirrored an
exploit framework, it would be pretty easy for them to be called out.
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 51, Issue 4
****************************************
