(no subject)

[ravencallscrows]

Bleh. Lunch break during training classes. Don't really have anything i want to eat, so i'll probably just continue checking mail and doing the odd bit here and there on the web.
Grumble of the moment about test training sessions like this one: Don't just define and illustrate what something is, tell me where to look for it and why it's a bad thing. If i hear one more person define "buffer overrun" today without giving a practical clue as to where to look for one in a product (not in something written specifically to contain one, so that it can easily be shown off) i think i'm going to throw things. Yes, they're bad. I understand in theory how they can be exploited, but if i'm supposed to spend the next three weeks looking for them all over the place, show me at least one place to look for them in a full fledged application instead in a text-based app that runs from the command line.
As with most things specifically designed for testers, this seems to be long on theory and short on practicality.
I don't know. Maybe it's different from the perspective of the individual application teams, since they deal with the components on a more intimate level than Setup does. Or maybe it's just that I'm too jaded with the whole thing to really be able to see anything beyond the most basic applications for what we're being taught.

Comments

[kingrat]

String input. That's where I look for them. I see it all the time in web apps. I dunno where it can go in setup type stuff, but I imagine that a prime place for them would be config files and registry settings.

[wingedelf.livejournal.com]

Thanks, Phil. That's pretty much the conclusion i'd come to, and it's nice to have it validated.
My complaint is equally valid for any of the stuff that was covered today. It was either assumed that all testers are idiot monkeys who need to have things explained very basically or one way or another missed an essential piece of the logic chain necessary for everything to be cohesive. Here's another example- someone talked for an hour and a half about SQL Injection as a method for disrupting web services. He even did a demonstration to illustrate what he was talking about. Unfortunately, there's a big difference between being able to drop a table on localhost by sending the appropriate drop table bleh SQL string when you know the table's called bleh because you just created it for the purpose of the demonstration and the process which one would have to go through to be able to do the same thing on a remote server without knowing the names of the tables. It'd have been far more useful to those in attendance to be able to watch the presenter work through figuring that out on a server someone else set up for the purpose than sitting and watching him create a table and then kill it from another process. Big deal. Even the dullest tester with no knowledge of SQL is going to be able to do that if you give him all the pieces of the puzzle up front. I don't see repeating that exercise to be beneficial to the product as a whole, though.

[kingrat]

sounds like the same spiel we got. before we completely separated from M$, we brought over the security guru for the talk it sounds like you got.

being a developer though brings a different perspective. I can easily see how one can use SQL injection to hack even when I don't know anything about the tables. but someone has to be pretty familiar with SQL to make that jump.

with buffer overruns in setup scripts, i would think that a big danger is that a lot of install scripts run as administrator, but the setup scripts themselves may not be locked down in temporary files, or the registry entries may not be locked down tight on the premise that they are temporary. so a malicious hack exploits that by starting an install, using a separate hack to script the registry change with a huge string, and then the install is compromised while running as admin. or it could be a local hack that is used to escalate priveleges.

admittedly, it's more work than it would be to send a large string to a server. but it could still happen.

Re:

[wingedelf.livejournal.com]

*nod* Elevated priviledge would be my concern as well. For the most part, though, that's not going to have any effect on the general user who's installing from a CD, or for the corporate user installing across a network, and, just thinking about deployment from an IT perspective, if you really want to f*ck your corporation, there are going to be ways of doing it that are far easier than recompiling binaries or going through all the effort that most of those hacks would entail- hell, there's a custom transform tool that's shipped with the product that's going to let an IT admin do it in a handful of easy steps.
Back to SQL- i'm not really well versed in it, but i understand in theory the logic chain in using SQL queries to have IIS fill in some of the blanks in what's known about the structure of a database- but actually seeing someone do it would make it a lot more tangible.
Then again, when i learned i could read damn near any code in a C-derivative language, it wasn't because i wanted to do anything with it (i'm decidedly a non-coder, but i do passably with scripting languages, and haven't any coding mainly because i don't want to), but because one of the senior dev leads in the department i worked in (this was the online gaming group at Cavedog, back before my MS return) had a series of scripts which we used in the process of keeping the online service running which needed to be documented for a potential buyer, and since i was playing test lead, production assistant, tech writer etc., i got to explain exactly what all the perl scripts did just from reading them, so in general i have a passable idea of what's going on behind the scenes. It'd just be nice to actually *know* that some of my assertions are correct, rather than relying on a pure black-box approach.