Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple CoreGraphics framework logging input data to /tmp

mozilla.org

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Apple CoreGraphics framework logging input data to /tmp

#11

Post by heinrich5991 »

stinos wrote: post #10
ceronman wrote: post #5

Earlier quoted context omitted.

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what. That's a fact in software development.

Sure, but the thing is: one developper (or a group of) said 'well let's enable this' and then nobody else reviewed that or thought 'hmm, surely it can't be good to just start logging pretty much everything'? Just wondering how that happens in large companies.

From the article:

>In OS X 10.10, this logging was turned on by default for some applications that use a custom memory allocator, such as jemalloc, because of an initialization bug in the framework.

So it seems to be a bug that it even got enabled.

Re: Apple CoreGraphics framework logging input data to /tmp

#12

Post by kbar13 »

stinos wrote: post #10
ceronman wrote: post #5

Earlier quoted context omitted.

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what. That's a fact in software development.

Sure, but the thing is: one developper (or a group of) said 'well let's enable this' and then nobody else reviewed that or thought 'hmm, surely it can't be good to just start logging pretty much everything'? Just wondering how that happens in large companies.

mistakes happen

Re: Apple CoreGraphics framework logging input data to /tmp

#13

Post by Create »

OpenSSL came with its own memory allocator, which is basically an optimistic allocator and caching wrapper around libc malloc()/free() that tries to save calls to malloc() by not actually free()ing blocks immediately but holding onto them for some time. This allows them to skip the actual memory allocation as long as they can accommodate any incomming malloc() calls from their unused blocks buffer, and if it actually has to allocate fresh memory it doesn't just allocate the amount of memory needed but speculatively allocates more and stashes the excess in its unused blocks buffer.

One of the artifacts of this behavior is that OpenSSL data isn't evenly spread throughout a processes heap, which is what one would expect if the memory was allocated purely on demand, but tends to cluster in regions that can be fairly long-lived. Now, what actually happens with Heartbleed is that it can only leak data directly adjacent in virtual memory to the data segment containing the Heartbeat payload, but due to that clustering of memory in use by OpenSSL the chances are fairly high this isn't just some random block of memory from the application's heap but a block containing other OpenSSL data. Like decrypted HTTPS requests, with passwords and stuff.

Re: Apple CoreGraphics framework logging input data to /tmp

#14

Post by acdha »

coldcode wrote: post #3

Very very few OSX apps use an alternate allocator so this was probably not noticed. Having written a commercial memory allocator before (for MacOS prior to OSX) the one in OSX is actually quite good for most people. I don't know why Mozilla decided they needed jemalloc but maybe it tested better for their usage. Still you would think tracking what's written to such a common directory would have been seen by someone a…

jemalloc goes back to Firefox 3:

http://blog.pavlov.net/2007/12/04/vlad-and-analysis-of-dtrac... http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

It looks like that was driven by cross-platform concerns – I don't know how good the OS X allocator was in that era but it looks like most of the benchmarking focused on Windows and having a single malloc which performed well on all of their platforms. At that time, Firefox still supported at least as far back as Windows 2000 and the rise of consumer Mac usage hadn't reached current levels.

Re: Apple CoreGraphics framework logging input data to /tmp

#15

Post by rmorell »

stinos wrote: post #10
ceronman wrote: post #5

Earlier quoted context omitted.

The bug is triggered by using a custom memory allocator. It's clearly an edge case. There will be bugs that slip over code review and/or testing no matter what. That's a fact in software development.

Sure, but the thing is: one developper (or a group of) said 'well let's enable this' and then nobody else reviewed that or thought 'hmm, surely it can't be good to just start logging pretty much everything'? Just wondering how that happens in large companies.

Nobody explicitly decided to enable the logging by default. It was caused by an uninitialized variable. Uninitialized variables result in undefined behavior, but can often go unnoticed in practice if the code around them results in the value in memory (or register) for that variable usually being a certain value. In this case, it happened to result in logging being disabled by default in most situations. But using jemalloc for the process rather than the standard malloc implementation was enough to cause the opposite result, apparently due to jemalloc poisoning malloc()ed regions (which overwrote the "usual" value).

Re: Apple CoreGraphics framework logging input data to /tmp

#16

Post by to3m »

Create wrote: post #13

OpenSSL came with its own memory allocator, which is basically an optimistic allocator and caching wrapper around libc malloc()/free() that tries to save calls to malloc() by not actually free()ing blocks immediately but holding onto them for some time. This allows them to skip the actual memory allocation as long as they can accommodate any incomming malloc() calls from their unused blocks buffer, and if it actually…

I don't understand the relevance.

Re: Apple CoreGraphics framework logging input data to /tmp

#17

Post by tljr »

Create wrote: post #13

OpenSSL came with its own memory allocator, which is basically an optimistic allocator and caching wrapper around libc malloc()/free() that tries to save calls to malloc() by not actually free()ing blocks immediately but holding onto them for some time. This allows them to skip the actual memory allocation as long as they can accommodate any incomming malloc() calls from their unused blocks buffer, and if it actually…

wut?

Re: Apple CoreGraphics framework logging input data to /tmp

#18

Post by Create »

to3m wrote: post #16
Create wrote: post #13

OpenSSL came with its own memory allocator, which is basically an optimistic allocator and caching wrapper around libc malloc()/free() that tries to save calls to malloc() by not actually free()ing blocks immediately but holding onto them for some time. This allows them to skip the actual memory allocation as long as they can accommodate any incomming malloc() calls from their unused blocks buffer, and if it actually…

I don't understand the relevance.

The bug is triggered by using a custom memory allocator. It's clearly an edge case.

Re: Apple CoreGraphics framework logging input data to /tmp

#19

Post by eis »

to3m wrote: post #16
Create wrote: post #13

OpenSSL came with its own memory allocator, which is basically an optimistic allocator and caching wrapper around libc malloc()/free() that tries to save calls to malloc() by not actually free()ing blocks immediately but holding onto them for some time. This allows them to skip the actual memory allocation as long as they can accommodate any incomming malloc() calls from their unused blocks buffer, and if it actually…

I don't understand the relevance.

This user seems to be a bot posting snippets of text he found "relevant".

Re: Apple CoreGraphics framework logging input data to /tmp

#20

Post by dahjelle »

ZoF wrote: post #7
dahjelle wrote: post #6

I'm using Firefox Developer Edition, and I don't see any CGLog_* files in /tmp at all. Am I missing something?

>This issue has been addressed in Mozilla products by explicitly turning off the framework's logging of input events. It's fixed now and anything you had in there was already auto-deleted at some point. You're likely not missing anything.

Awesome—thanks!
Post reply on HN