3 ms·

Wow. All you have to do is give it an empty response, and it accepts it as valid and lets you in. How did this get missed in QC? The first thing I try doing wh

Wow. All you have to do is give it an empty response, and it accepts it as valid and lets you in. How did this get missed in QC? The first thing I try doing while I'm working on my little game is seeing if null or empty inputs allow things that should not happen to happen with each command/function I add into the system. I write the code, see if it compiles, and if it does I immediately test the function in-game with any potentially invalid string/argument I can think to give it. Isn't input testing/validation step #1 in QC for code?

tyingq 10y ago
>How did this get missed in QC? Probably a focus on testing only at the UI level. You would have to have a tool that allowed you to edit or generate your own Auth headers to find it. Or have unit testing that fuzzed, or at least supplied obvious bad stuff like nulls or empty inputs. Not arguing it's good, but it's not uncommon. I've seen lots of places with webapps where the vast majority of tests are selenium driving form inputs, clicks, etc. That misses things like this, or client side cookie manipulation, etc.
ajross 10y ago
While I'm sure you are right that you would totally never do something like that, it's likewise a truism that virtually all security goofs like this are commited by programmers who think they'd totally never do something like that. To wit: I don't believe you. What almost certainly happened here is that, as someone else in this thread mentions, someone came by to fix an automated warning about the use of strcmp(a, b) and replaced it with strncmp(a, b, strlen(a)) instead of strncmp(a, b, strlen(b)). Easily 90% of code reviewers wouldn't catch that mistake (especially if it came along with a truckload of other such fixes), and as it's a maintenance change no new tests would have been written for it. The only way to catch this would have been to already have written and deployed a test that expressly tested an empty string password. That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career. Did you deploy a test and integrate it into CI for every one of them?
- tyingq 10y ago
  It was trickier that that even. It wasn't an empty password. It was an empty digest auth response, something like this is the normal path, inside the browsers code...not your own code. HA1=MD5(username:realm:password) HA2=MD5(method:digestURI) response=MD5(HA1:nonce:HA2) So you have to hijack the header value the browser sends...not just send an empty password.
- lightedman 10y ago
  "That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career." No, not a single one. I tend to work on projects with a bit more complexity than that (including designing the required hardware on top of it if something suitable doesn't already exist.)
ams6110 10y ago
Well most servers ship with IPMI and a default username/password of admin/admin or something equally guessable. There's some assumption that a competent administrator is managing them.
- tyingq 10y ago
  Not sure what you mean here. A competent admin that set a strong password wouldn't have helped with this. I guess they would have firewalled access, but there's still a bug/hole.

tyingq 10y ago

>How did this get missed in QC? Probably a focus on testing only at the UI level. You would have to have a tool that allowed you to edit or generate your own Auth headers to find it. Or have unit testing that fuzzed, or at least supplied obvious bad stuff like nulls or empty inputs. Not arguing it's good, but it's not uncommon. I've seen lots of places with webapps where the vast majority of tests are selenium driving form inputs, clicks, etc. That misses things like this, or client side cookie manipulation, etc.

ajross 10y ago

While I'm sure you are right that you would totally never do something like that, it's likewise a truism that virtually all security goofs like this are commited by programmers who think they'd totally never do something like that. To wit: I don't believe you. What almost certainly happened here is that, as someone else in this thread mentions, someone came by to fix an automated warning about the use of strcmp(a, b) and replaced it with strncmp(a, b, strlen(a)) instead of strncmp(a, b, strlen(b)). Easily 90% of code reviewers wouldn't catch that mistake (especially if it came along with a truckload of other such fixes), and as it's a maintenance change no new tests would have been written for it. The only way to catch this would have been to already have written and deployed a test that expressly tested an empty string password. That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career. Did you deploy a test and integrate it into CI for every one of them?

tyingq 10y ago
It was trickier that that even. It wasn't an empty password. It was an empty digest auth response, something like this is the normal path, inside the browsers code...not your own code. HA1=MD5(username:realm:password) HA2=MD5(method:digestURI) response=MD5(HA1:nonce:HA2) So you have to hijack the header value the browser sends...not just send an empty password.
lightedman 10y ago
"That's surely a good test to have, but come on, be honest: you've probably written a bunch of "password" style checkers in your career." No, not a single one. I tend to work on projects with a bit more complexity than that (including designing the required hardware on top of it if something suitable doesn't already exist.)

ams6110 10y ago

Well most servers ship with IPMI and a default username/password of admin/admin or something equally guessable. There's some assumption that a competent administrator is managing them.

tyingq 10y ago
Not sure what you mean here. A competent admin that set a strong password wouldn't have helped with this. I guess they would have firewalled access, but there's still a bug/hole.