31–40 of 47 posts
Leaking two random bytes and in some cases just padding bytes to user space is not the end of the world and I don't get why there are so many negative comments blaming Apple for not handing out a handsome bounty for this bug.
It's still a security bug. Often, multiple bugs like this are chained together to create one very nasty exploit. I agree that this bug probably does not deserve a massive payout, but I think $3,000-5,000$ is appropriate.
Seems like something to be integration tested in the future. Honestly surprised this slipped through.
I am not surprised. First, it's a subtle bug. Second, in C/C++. a lot of times you get unlucky when reading uninitialized memory. Basically, the bug does not occur when you test the code on your machine or when you run the automated tests. Another problem is writing good automated tests is hard and often skipped. Lots of software engineering teams talk about the wonders of automated tests. Unfortunately, many automat…
Earlier quoted context omitted.
It's still a security bug. Often, multiple bugs like this are chained together to create one very nasty exploit. I agree that this bug probably does not deserve a massive payout, but I think $3,000-5,000$ is appropriate.
You're joking. This is a $10 bug.
Earlier quoted context omitted.
I am not surprised. First, it's a subtle bug. Second, in C/C++. a lot of times you get unlucky when reading uninitialized memory. Basically, the bug does not occur when you test the code on your machine or when you run the automated tests. Another problem is writing good automated tests is hard and often skipped. Lots of software engineering teams talk about the wonders of automated tests. Unfortunately, many automat…
Right, but this was caught basically instantly by Asan.
- int new_value = *(int *)oidp->oid_arg1; + int new_value = *(uint16_t *)oidp->oid_arg1; Why not just have `uint16_t new_value = ...`? Ahh, because `new_value` is being given to `sysctl_handle_int(..., &new_value, ...);` which of course expects an `int`. So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`? It smells like there could easily be tons of o…
> So then it begs the question: if the value is really a `uint16_t`, then why is it being handled through a plain `int`? I don't think it begs the question, but it does raise one!
Earlier quoted context omitted.
Is there any reason to assume a conspiracy and drama around the bounty here other that just being bored and cynical? Apple has a well known security bounty program https://security.apple.com/bounty/
So the researcher didn't get a bounty from Apple then, no?
Earlier quoted context omitted.
Well there's the so-called usual arithmetic conversions that will basically convert every uint16_t to an unsigned int. The C and C++ languages do a silent conversion on your back anyways so you might as well make it explicit.
Usually promotions are to signed int, not unsigned. (With some exceptions. But every uint16_t value can fit in int.)