Penetration Testing Scope - Murky Waters Ahead!

A colleague of mine called me tonight with what sounded like a simple question on penetration testing scope.  But he's a smart guy.  If there was a clear cut answer, he wouldn't have solicited advice.

Scope, fracking scope...
See, the problem had to do with scope.  I intend to cover why I setting out of scope boxes/services is generally stupid in a later post.  But that aside, determining what's in scope can be a hard topic.  It's so confusing that the SANS SEC560 course on penetration testing actually pays it quite a bit of attention (and rightfully so).  A bad scoping document can make or break a penetration test when expectations aren't met (on either side).

Here's the problem. Many clients don't want you to test their web applications.  Of course no self respecting attacker would ever use one of those to gain access to your network. And oh yeah, about that social engineering stuff... that's unfair. Don't trick the user. Finally, we already know our Acrobat Reader is out of date.  Please don't run any client side attacks.  Without explicitly saying so, they've more or less restricted themselves to network services only.

Where do services end and web apps begin?
Here's the problem: my colleague has just that scope - no social engineering, no client side apps, and no web apps.  While scanning, he found a publicly available web server running an outdated version of PHP.  The question is whether it's in scope to exploit.  The purist in me wants to say "of course it's in scope."  However, I'd expect a fight from the client if he exploits it.

CVE 2012-1823 is a great example.  It offers remote code execution, but only in certain fairly specific circumstances.  I know some purists out there will argue that CVE 2012-1823 was HUGE (and if you were exploited by it, I'm sure it feels that way).  However, not every server running an affected version of PHP shows up as vulnerable (even if the circumstances to exploit it don't exist on that server).  However, it's the server configuration (not the web application) that controls whether the vulnerability is exploitable.  This one seems like an easy win for the services column and clearly not a web application.

CVE 2011-1938 isn't so clear cut.  This vulnerability relies on the socket name of a Unix socket in the function socket_connect().  Now I feel that I can successfully argue that user controlled values should never determine the name of a Unix socket.  But let's suppose that your web app developer was huffing  glue the night he wrote that part of your web application.  It turns out you can exploit this web application, but only because PHP itself is vulnerable.  We can agree that the web app developer probably didn't follow awesome coding practices, but his code itself isn't vulnerable.  So where does this one land?  Again, I say this is in scope for network services, but I expect some disagreement here.  The waters have definitely gotten murky.  I expect an embarrassed CISO would argue that this was a web application problem and whine his way out of a finding.

Thoughts, dissenting opinions?
I don't have all the answers (although my six year seems to think so).  If you think I've missed the boat here, let me know.  If you have any war stories to share, feel free to tell me about those too.