Security scrubbing of Python code – PyChecker or nothing?

I’m hardly versed in the history or design of the Python programming language (I just started reading up on it this week), but I know this much already: Python is intended to be a very easy-to-use scripting language, minimizing the burden of silly things like strongly typing your data (not to mention skipping the arguable burden of compiling your code).

Most developers don’t have two spare seconds to rub together, and are hardly excited at the prospect of taking code that they finally stabilized and having to review/revisit it to find and fix potential security bugs.  Manually droning through code has to be about the most mind-numbing work that most of us can think of eh?

On the other hand, static analysis tools are hardly an adequate substitute for good security design, threat modelling and code reviews.

Still, static analysis tools seem to me a great way to reduce the workload of secure code reviews and let the developer/tester/reviewer focus on more interesting and challenging work.

Is it really practical to expect to be able to perform complex, comprehensive static analysis of code developed in a scripting language?  I mean, theoretically speaking anyone can build a rules engine and write rules that are meant to test how code could instruct a CPU to manipulate bits.  It’s not that this is impossible – I’m just wondering how practical it is at our current level of sophistication in terms of developing software languages, scripting runtimes and modelling environments.  Can we realistically expect to be able to get away with both easy development, ease of maintenance (since the code isn’t compiled) and robustness of software quality/security/reliability?

I’m certainly not trying to disparage the incredible work that’s gone into PyChecker already – anything but.  However, when a colleague asks me if there are any other static analysis tools in addition to PyChecker, I have to imagine that (a) he has some basis for comparison among static analysis tool and (b) that PyChecker doesn’t quite meet the needs he’s come to expect for checkers targeted at other languages.

Slashdot | Is Assembly Programming Still Relevant, Today?

Seemed an especially relevant discussion, given my recent immersion in Intel (where they build chips that run the assembly code spat out by compilers – or that generated by really hardcore software engineers).

Every once in a while I get lured in by the taunts from these demi-gods: until I learn the depths of what’s going on behind the scenes, having a true understanding of how the software works (and how to make it work/work better) will continue to elude me.

I pride myself on being able to dig deep to troubleshoot weird/opaque issues, and to come up with better ways to make existing software work. No matter how much I already know about TCP/IP headers, registry structures, sysinternals tools, APIs, and DLL dependency mapping, my natural curiosity always gets the better of me. I want to be able to answer the next layer of questions, and to do that it seems I have to keep peeling away the layers of how my computers work.

I must’ve hit a natural inflection point recently, as I finally made the leap from skimming other people’s code to writing my own. I can’t exactly say whether it was just time + frustration that finally drove me over the edge, or if I recently reached some level of expertise in my problem-solving skills. One way or another, something finally allowed me to be able to articulate the problems (and possible steps to solving them) that is necessary to both articulate achievable software requirements and write the code that might actually approximate fulfilment of those requirements.

All that said, I think it’s hard to imagine going from VB.NET to Assembler without envisioning a cliff-face learning curve. Good freakin luck making that leap. I’ll be lucky if I get my brain wrapped around C++ and Java in the next year or two, let alone non-OO languages or their machine-level equivalents. Heh.

So what does this thread on Slashdot tell me, exactly? It’s a typical array of folks like me just trying to earn a living, along with the requisite grumpy old farts and disrespectful kiddies. Seems to me that there are three main bodies of opinion:

  • The largest number of folks are fine having some level of understanding of what goes on between the CPU microcode and the high-level programming languages – i.e. the actual compiled code that’s run by the CPU. If you don’t understand what’s going on under the hood, then you’re likely to make some pretty classic mistakes that lead to less-than-stellar performance, security or both.
    • So long as you can *read* some assembler and maybe add a dash of ability to predict how your own code might behave at this level, then you’re worthy of being called a professional coder.
    • One poster commented, “It’s good to know what goes on under the hood, sure. But in many, many software developer tasks, early optimization is the root of all evil.” I’m in full agreement with this philosophy – diving into the code head first (or head-up-arse first) does no good if the purpose for writing the code isn’t understood, and the major functionality hasn’t been demonstrated to be possible (let alone workable as a whole).
    • Multiple posters made the point that, while a really skilled developer can write really efficient and elegant assembly code, 99% of developers are (a) hacks or (b) wasting time doing something that quality, modern compilers do really well these days. “It’s no use being a mediocre assembly programmer.
  • The folks I really love are the hardcore “That’s no’ oatmeal!” types – until you can write your code directly in assembler, don’t bother me kid, and I hope your code never tries to infiltrate my box. Keep your crap code out of my way, ’cause obviously you suck until you’ve mastered byte-by-byte electron pushing.

However, there was one insight that really caught my eye: [among the reasons you might need proficiency in assembly language] “You’re writing malware to exploit a buffer overflow vulnerability.” Those writing the really quality malware these days are taking advantage of any and every layer of the software stack – that’s where the money is, and it’s where you can stay as far ahead of the originators of the software you’re exploiting as possible. [Given the increased entree of organized criminals into this arena, I expect the incentives for skilled coders here to only increase.]

And I can’t wait for the hackers to focus their attention on exploiting implementation idiosyncracies in the virtualization stacks and the underlying hardware – CPUs, chipsets, video, I/O, storage/mobo/video/networking firmware, etc. etc. etc. Imagine trying to roll out fixes for hardware… (rolled eyes)

Link to Slashdot Is Assembly Programming Still Relevant, Today?

Week One at Intel

Feels like a comfortable pair of shoes… strangely, despite all the advice I’ve heard from friends and colleagues that Intel’s corporate culture is very different from Microsoft’s, I felt pretty relaxed with the information that’s been thrown at me so far, and so far I feel confident I’ll be able to take on the responsibilities that are thrown my way.

I also feel welcomed at Intel. Obviously there were a few folks who wondered who “the new guy” was who took over the empty cubicle there, but everyone I’ve met so far has made me feel welcome and respected.

Respected? What the h*** does he mean by that? Well, I must confess I worried that folks would think that a “software guy” from Microsoft wouldn’t have much to contribute at a hardware company like Intel. And in the first few hours of being there, I got a really overwhelming sense that Intel is incredibly “engineering-friendly”. [Hell, the maps on the walls of the buildings that tell you how to get around look like they’re straight out of AutoCad.] Not unlike Microsoft, where I always felt a little “outside” because I didn’t know how to code, I get this sense from Intel that if you don’t grok hardware, and aren’t an engineer, then you’re second-class and will always be climbing uphill to prove yourself.

The jury’s still out on whether a non-engineer can really earn “first-class citizen” status at Intel, but given the number of times I’ve heard my security colleagues here reference Microsoft as an organization that’s well ahead on the security front, I feel like my credentials should be reasonably intact for now.

Tidbits that I didn’t know until I got here:

  • Intel is a cubicle farm – everyone has a cubicle here, allegedly up to the executive class. It’ll take me a while to get used to the cacaphony of shared conversations and random noises, but I really hope I adjust soon.
  • The cafeteria here is even nicer than the ones on Microsoft campus – I had a Tempeh curry dish yesterday (yum!), and today I discovered the self-serve sandwich bar – take your bread, load up whatever fillings and toppings you like, and pay by the ounce. [I had inch-think tuna salad, a muffin and an apple for $5.31 – darned reasonable.]
  • These guys seem to have standardized exclusively on Thinkpads – it’s amazing after seeing all the wild variations of hardware at Microsoft to see just *one* OEM’s PCs everywhere. It’s almost…cultish. Still, if you’re going to choose only one notebook, I can think of much worse choices than these.
  • Microsoft’s concept of “long-timer” is pretty paltry compared to Intel. Ten years at MS is an accomplishment, and anyone with 15+ years at MS is considered a “volunteer” (i.e. part of the generation who earned enough cheap stock options to not need the paycheque, but still comes to work for some reason). I’m working with a guy who’s been with Intel for 27 years, and I’ll meet another on Friday who’s been with Intel for 30. Holy crap – thirty years ago, I was mastering finger-painting, while these guys were pioneering circuit designs.

I’m still figuring out what I’ll be doing around here, but so far it looks pretty exciting. I’ll tell you more about it in the near future.

How to get a Process’ current security context – mystery and teaser…

…so I’ve crossed the threshold, and now I’m writing VB code in .NET 2.0.  It’s been a fascinating experience – going through fits and starts of trying to find a project motivating enough to keep me working on it through the inevitable “slump”.

For anyone who’s new to coding, and self-taught (like me), there’s the initial rush of being able to construct whatever it is your favoured “for morons” teaching book walks you through.  Then there’s the first tentative steps into adding something for which you don’t have stepwise instructions – which is just about anything else that might be useful – which is quickly followed by the frustration of knowing that you *should* be able to construct that next section of code, but having no idea why it doesn’t work the way you want it to work.

I’ve done this probably a half-dozen times, and every time I get discouraged that the damned code just doesn’t flow from my fingers.  I’ve been stymied by, in no particular order:

  • How to cast an Object to (as? into?) an Interface
  • How to use a GetEnumerator method
  • What the hell goes into a DataGrid
  • How to Dim an Object as something other than a String
  • When and where to define and instantiate an Object (e.g. inside the For loop?  outside the Private Sub?  Inside a Public Sub?)
  • How to write code in separate classes and still be able to take advantage of variables defined in the “other” Class

However, I think I’ve come up with sufficiently self-interested projects to complete at least ONE of them before I let myself fail at this AGAIN.

The latest fiasco was the last three attempts in which I’ve been trying to filter out only those processes that were launched in my user context (e.g. Run key, Startup folder, Start menu).  I’ve been failing to (a) identify an actual username from the info supplied in the System.Diagnostics.Process class, (b) construct an equivalent username to what comes from the My.User.Name property, and most recently (c) actually filter out the processes started in other users’ context (e.g. svchost.exe, wininet.exe, csrss.exe).

Here’s the current code mess I’ve constructed:

Dim process As New System.Diagnostics.Process
Dim dictionary As New System.Collections.Specialized.StringDictionary
Dim entry As New System.Collections.DictionaryEntry
Dim UsernameFromProcess As String = “”
Dim DomainFromProcess As String = “”
Dim Username As String = My.User.Name
Dim MyApplications As New Collection

dictionary = process.StartInfo.EnvironmentVariables

For Each entry In dictionary
    If entry.Key.ToString = “username” Then
        UsernameFromProcess = entry.Value.ToString
    End If

    If entry.Key.ToString = “userdomain” Then
        DomainFromProcess = entry.Value.ToString
    End If
Next entry

Dim QualifiedUserName As String = “”
QualifiedUserName = DomainFromProcess + “\” + UsernameFromProcess

If QualifiedUserName = Username Then
    MyApplications.Add(process)
EndIf

So why does this always result in adding the process to the MyApplications collection?  I woulda figured that the environment variables for processes started in other users’ contexts would reflect that user’s environment.  E.G. if csrss.exe starts in the SYSTEM context, then it should have USERDOMAIN =  [nul] and USERNAME = SYSTEM.  Whereas, when I launch Word from the Start Menu, its environment will include USERDOMAIN = REDMOND and USERNAME = mikesl.

If you’d like to see how I finally solved/worked around this little mystery, check out the CacheMyWork project on Codeplex.

Heading to Portland, Leaving Microsoft…

After five years living in Seattle (which my wife considers a pale comparison to Portland), Robin has been offered a kick-butt job at a really cool-sounding law firm in Portland, where she’ll practice tax-exempt and estate planning law.  Obviously we’ll be moving to Portland very shortly (in fact, in the next few weeks it looks like…)

That put me in the difficult position of considering whether to remain with Microsoft or venture out to new horizons.  Working for my current team (Security Accelerators – Security and Compliance) has been awesome, but it just can’t be done when not stationed on campus.  My next-best option would be to re-join Microsoft Consulting Services, but I don’t think I’m ready to go back to a delivery role after a few years of the intellectual rewards of working on the fringes of R&D.  I started my career at Microsoft in MCS Canada (take off eh!), and though I don’t regret those experiences, I’m more interested in making broad impact on the security of large numbers of individuals and organizations than go back to the one-at-a-time approach (not yet, anyway).

Looking around Portland, there’s a lot of high-tech opportunities but the big players are Intel and McAfee.  Against all odds, a really incredible job opening was available in a smallish, growing group at Intel.  Intel seems like a really interesting place to work, and the group I’m joining has their fingers in many pies: product pen testing, product security development lifecycle, product security consulting.  [I’m pretty sure I’m mischaracterizing their efforts but I’ll clear that up shortly.]

So yes, I’m leaving Microsoft and joining Intel!  For those of you that know me personally, this may come as a shock that I’m joining another international corporation (one good friend of mine thought I’d join a Save the Whales or militant tree-hugging organization – heh :), but it’s just too tempting to pass up: leveraging my past experiences in a new environment, learning a whole new set of technologies around hardware development, software & hardware programming, and stepping into a new role with new perspectives, leaders and fresh thinking – how can I beat that?

One of my colleagues asked me to start blogging about life after Microsoft (aka life in my new job), and I think I’ll take him up on that.  It should be fun to reflect on my new experiences, especially after so long in the belly of the Beast. 🙂

‘Embarrassed’ Gun Suspect Sues Microsoft After FBI Finds Sex Videos On His PC – Technology News by InformationWeek

You’re kidding, right?  This guy surfs for porn, bases a purchase decision on his need to surf for porn anonymously, and then sues Microsoft when he (inevitably) gets caught?  I know there are many folks out there that don’t understand the difference between “delete” and “wipe all traces”.  I’ve had to explain this to countless folks who want to understand how to actually protect their data from snoopers and thieves.

However, I’ve rarely known anyone with “questionable” surfing habits – and especially those who know their habits are questionable or at least embarrassing – to not investigate deep into the computer to make sure there are six ways from Sunday protecting them from unaware spouses, curious kids and wary employers.

What you do in the privacy of your own computer is your business, and I’m hardly condemning this guy for his legal and not-uncommon activities.  Still, he needs to cash a reality check if he has some expectation of privacy from law enforcement officials when he’s relying only on “automated delete” features of any piece of software.  There’s tons of discussions, web sites and vendors hawking cheap/strong/free encryption products, disk wipers, “trace erasers” and the like.

It’s no coincidence that Zimmerman’s PGP stood for “Pretty Good Privacy” – if you want to keep something to yourself, you’d better lock it behind a reasonable key and not leave the kitchen window wide open.

Heck, at least try some of the in-box encryption technology, before you go laying blame at Microsoft’s feet.  Then you’ve got at least a toe or two to stand on…

Link to ‘Embarrassed’ Gun Suspect Sues Microsoft After FBI Finds Sex Videos On His PC – Technology News by InformationWeek