Full Disclosure mailing list archives
Re: Re: No Subject
From: Bradford Shedwick <bjshedwick () yahoo com>
Date: Tue, 21 Oct 2003 11:43:51 -0700 (PDT)
Anyone know what runs on tcp port 255? Any known viruses or trojans? Napoleon Michal Zalewski <lcamtuf () ghettot org> wrote: On Tue, 21 Oct 2003, Frank Knobbe wrote:
just to clarify, you mean on machines with a paged memory addressing scheme, right? I mean, byte-order itself is not the catalyst, but the fact that an address is formed by a page and a pointer within that page, right? (I'm not nit-picking, just trying to visualize...)
I'm not quite sure what you mean by "paged memory addressing" - but if you mean a CPU feature, nope, it has nothing to do with it. Memory allocation is done on a higher level. The issue is that malloc structures are often created like this: .--- user data - pointer returned by malloc() --------. | | | CHUNK 1 | CHUNK 2 .--.--------------------------------. freed chunk .--.------------ `--`--------------------------------' empty space `--`------------ | | `--- control data (pointers to next and --------------' previous chunks) Chunks are of arbitrary length in linear memory space, one level above paging, and have a tiny piece of control data just before the pointer returned by malloc() that points to previous and next chunks, or stores some other information that makes it easy to create and unlink chunks as they get allocated or released. The process of unlinking chunk number X is nothing more than writing to the control structure of X-1 so that it points to X+1 as the next chunk, and of X+1, so that it points to X-1 as a previous chunk. The empty space is then added to the pool of space available for use. Now, if you can cause zeros to be written past one of the chunks, you can sometimes partly overwrite control structures of the next chunk, should there be any, and make 'prev' or 'next' somewhat different. On big endian, most significant bytes go first, and you are not likely to get a sane pointer just by overwriting parts of it with zeros. On low endian, you can change a pointer such as: 0x08049648 ...to be one of the following: 0x08049600 0x08040000 0x08000000 ...with some luck, one of the areas will contain either user-dependent data, or something that suits us well for other reasons. When this next chunk is then freed, free() can be tricked into thinking the previous or next chunk has its control structures at this "evil" address. This region will be written (which is a possible attack vector if it is used for anything interesting later on), and will be used in the future; if it contains user-dependent or otherwise interesting data, you can hope for the subsequent pages to be freed, this time writing not to a partly overwritten on-heap pointer, but to, for example, stack. But then, some implementations use guarded free() and malloc() - OpenBSD is a good example, IIRC. And not always there is something to overwrite, any interesting data in the memory - in OpenSSH case, there is very little code executed past the fault condition, and if you can't exploit a number of free()s or something near libc exit() handler, no such luck. Zero overwrites are a tricky business.
The million dollar question is: Looking at the code in question for the SSH heap-0-overwrite, does it appear to be feasible or not?
It's not as much about looking at the code, but looking at the library malloc() implementation, and then figuring out what can be put on heap and where. I am way too lazy / too busy to give it much thought - I don't see any benefit from writing an exploit or proving (?) it is not exploitable. At first sight, it does not seem to be exploitable on some platforms, on others, is uncertain at best. Quite frankly, I would expect the exploit to leak already, or be developed independently, so I am sort of skeptical. If it is exploitable and there is an exploit, the public will sooner or later find out, don't force it if there is no good reason... -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-10-21 18:17 -- http://lcamtuf.coredump.cx/photo/current/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html Bradford Shedwick American by birth, Patriot by choice --------------------------------- Do you Yahoo!? The New Yahoo! Shopping - with improved product search
Current thread:
- No subject Pocjfr (Oct 13)
- Re: No subject Gregory A. Gilliss (Oct 13)
- <Possible follow-ups>
- No Subject mitch_hurrison (Oct 20)
- Re: No Subject Frank Knobbe (Oct 20)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Frank Knobbe (Oct 21)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Bradford Shedwick (Oct 21)
- Re: Re: No Subject Frank Knobbe (Oct 21)
- Re: Re: No Subject Michal Zalewski (Oct 21)
- Re: Re: No Subject Paul Schmehl (Oct 21)
- Re: Re: No Subject Byron Copeland (Oct 21)
- Re: Re: No Subject Peter Busser (Oct 22)
- Re: No Subject Frank Knobbe (Oct 20)
- Linux (in)security (Was: Re: Re: No Subject) Peter Busser (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Bruce Ediger (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Darren Reed (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Gary Flynn (Oct 22)
- Re: Linux (in)security (Was: Re: Re: No Subject) Ron DuFresne (Oct 23)