Full Disclosure
Posted by Vulnerability Lab on May 04
Document Title:
===============
Cisco (Newsroom) – Client Side Cross Site Scripting Vulnerability
References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1464
Release Date:
=============
2015-04-24
Vulnerability Laboratory ID (VL-ID):
====================================
1464
Common Vulnerability Scoring System:
====================================
2.5
Product & Service Introduction:…
Posted by Vulnerability Lab on May 04
Document Title:
===============
HUAWEI MobiConnect 23.9.17.216 – Privilege Escalation Vulnerability
References (Source):
====================
http://www.vulnerability-lab.com/get_content.php?id=1389
Release Date:
=============
2015-05-04
Vulnerability Laboratory ID (VL-ID):
====================================
1389
Common Vulnerability Scoring System:
====================================
6.7
Product & Service Introduction:…
Posted by PIN on May 02
We’ll but keep in mind here that the knowledge we are talking about is
based on the binary image as far as I can tell and knowledge of the order
of mapping, which given the mechanisms in place for privilege separation or
at least common forking a child is not that far of a stretch. “I am mapping
X and there will be Y mappings with a total size of Z before me whose base
address is A from the first/last loaded module”
Well but these…
Posted by Tavis Ormandy on May 02
That wasn’t what I said.
Sure, If code with knowledge of an address is willing to act as an
oracle, then ASLR is not useful. This is really just an indirect (and
unlikely) way of leaking an address though.
Well, if you know in advance which address to leak you can arrange for
it to be a useless one, it would usually have to be MMAP_FIXED and be
sanitized (think KUSER_SHARED_DATA on Windows or the vsyscall page on
Linux) so as not to weaken…
Posted by PIN on May 02
Really? Because leaking a heap address in windows, openbsd, etc doesn’t
yield a full collapse of all loaded modules randomization given the
preconditions; I’m asking that it’s not just my box exhibiting this
behavior- which is a long story why it must just be mine.
considered a
Well, you are somewhat missing the gravity here. If this is generally
reproducible, you don’t need the address to leak, you just need a series of…
Posted by Tavis Ormandy on May 01
PIN <zero () asac co> wrote:
It sounds like you’re asking “If I can learn an address, have I defeated
ASLR”, and the answer is usually yes. It depends on the circumstances of
course, but leaking any address to an attacker would usually be considered a
bug and renders ASLR essentially useless.
For example, if you can find some JavaScript that tells you the address of
an object on the heap or the base address of a module,…
Posted by Lee on May 01
crypto isakmp aggressive-mode disable
should be the counter-measure.
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-cr-book/sec-cr-c4.html#wp7822516900
To block all Internet Security Association and Key Management
Protocol (ISAKMP)
aggressive mode requests to and from a device, use the
crypto isakmp aggressive-mode disable
command in global configuration mode.
Regards,
Lee
Posted by Cédric Picard on May 01
If you are looking for informations about the bug behind CVE-2008-568
it is described in length by Tobias Klein (the discoverer) in the
third chapter of his book “A Bug Hunter’s Diary”.
Posted by Michal Zalewski on Apr 30
Looks like: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5689
Posted by Ian Neal on Apr 30
It appears to be a simple typo; a quick search for “Linux Kernel Solaris
5.10 Local Root Exploit CVE” finds [1]; the CVE number is CVE-2008-5689.