Friday 26 August 2011

Hunter Two

Via bash.org

I telephoned the 90s, and overheard this chat on IRC:

[Cthon98] hey, if you type in your password, it will show as stars
[Cthon98] ********* see!
[AzureDiamond] hunter2
[AzureDiamond] doesn't look like stars to me
[Cthon98] [AzureDiamond] *******
[Cthon98] that's what I see
[AzureDiamond] oh, really?
[Cthon98] Absolutely
[AzureDiamond] you can go hunter2 my hunter2-ing hunter2
[AzureDiamond] haha, does that look funny to you?
[Cthon98] lol, yes. See, when YOU type hunter2, it shows to us as *******
[AzureDiamond] that's neat, I didnt know IRC did that
[Cthon98] yep, no matter how many times you type hunter2, it will show to us as *******
[AzureDiamond] awesome!

(pause)

[AzureDiamond] wait, how do you know my password?

(pause)

[Cthon98] I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause it's your password
[AzureDiamond] oh, ok.

SDL Tools TFS 2010 Update

Better, Late

Team Foundation Server 2010 takes credit for most of the just-released updates to Microsoft's SDL toolset:

Threat Modeling Tool v3.1.8

The main pre-coding system security analysis tool has been updated with a number of bug fixes, improving the stability of the product's Visio 2010 and TFS 2010 support. 6MB msi.

MiniFuzz Tool v1.5.5

This SDL verification phase helper has also benefited from several stability-related bug fixes, and improved control of target application shutdown. It too has had TFS 2010 support added. 2MB msi.

RegExFuzz Tool v1.1.0

H Beam Piper and John Scalzi's retro SF aside, this is my favourite little fuzzy. It allows checking against a specific class of DoS attack, via regular expression patterns with exponential evaluation times. The update again contains a number of bug fixes based on version 1 feedback. 2MB msi. Unfortunately there are still a couple of unresolved known issues, albeit fairly minor ones. From the supplied documentation (ReadMe.rtf):
  1. The tool does not handle nested anchors in a regular expression. A regular expression can be assumed to start with ‘^’ and ended with ‘$’. If these tags or their variants are included in a target regular expression, the tool will throw an unhandled exception. The work-around is to break up the nested regular expression and test the resulting regular expressions individually.

  2. The tool requires that hexadecimal (‘\x’ prefix) characters within the regular expression be 2 characters. Those with a 0-padding assumed single character description will cause the tool to throw an unhandled exception. The work-around is to make all hexadecimal character descriptions two characters ‘\xCC’.

Tuesday 23 August 2011

FOADIACFWLS

Turning the Heat on the Cold Callers

Got another phone call yesterday from a lady in India, number withheld, asking if I had a Windows PC. None of your business, I informed her. It may be none of my business, but we are having a lot of trouble with the infections on your computer! she offered.

I thought about stringing her along, as I usually do; but I was busy. I had work to do. And I'm getting a bit tired of these organised criminal gangs of cold calling bastards, ripping off innocent and vulnerable users for hundreds of pounds with their fake antivirus scams. So on something of an impulse, I suggested: Fuck off and die in a car fire with leather seats!

Her immediate response was: You fuck off, you son of a bitch. [click] [bzzz]

Now I'm going to take a wild guess, that a genuine technical support organisation would have had a much higher level of professionalism than that. Maybe next time I'll go with I can tell you I don't have money. But what I do have are a very particular set of skills...

Oh! and also, wouldn't it be great, using a combo of tech, psych, and you know, Jeff Goldblum, to be able to upload a virus to them?

Sunday 21 August 2011

Cheap Chips and Network Security

(Via Charlie Stross)

In 1980 two eminent computer scientists were discussing trends in microprocessor production. One objected to the other's claim, "But there's no market for such cheap chips! What are you going to do, embed them in door handles?"

Five years later, checking into a hotel, he suddenly realized he was using a magstripe card to open his room door. There was a microprocessor in the door handle.

This piece is an extension to Charlie's brilliant, speculative USENIX 2011 Keynote: Network Security in the Medium Term, 2061-2561 AD. Both articles are highly informative and entertaining, written by one of our greatest living Science Fiction novelists - who also happens to have penned the first published "mainstream" technical review of Linux (in 1994), among scores of similar articles during his tenure at Computer Shopper. And both are, of course, highly recommended reading.

Thursday 11 August 2011

Simple Regex #4: Assertions

That Old Saw

Another Regex question, another blog post! This time, Colleague A wants to highlight search terms by inserting some CSS spans into his HTML. It's the old problem of ignoring the content of tags during substitution. For example, suppose he highlights the search term school by applying the CSS class xred. This causes injection of spans like this into his output:
Alan went to class at <span class="xred">school</span> next day.
So far the rendering is as expected:
Alan went to class at school next day.
Trouble is, he next wants to highlight the search term class in xgreen:
Alan went to class at school next day.
Doing another simple replace operation would cause the new, "false positive" instances of the term class (occurring within the previously added HTML tags) to be incorrectly incorporated into new xgreen spans, resulting instead in invalid markup, and an onscreen train wreck.
Alan went to class at class="xred">school next day.
The following method of avoiding substitutions within tags is far from the best available solution, even among those offered by Regex. However, it does provide a conveniently simple example to let me introduce another Regex concept, namely Assertions.

Zero Width Assertions

In the context of regular expressions, an assertion is simply a statement about the context of the current match. The simplest examples are the "begins with", "ends with" and "exact match" assertions, which use the ^ and $ characters to match the beginning and end of the line, respectively. Suppose our input is 12345. Then the pattern 234 will match this successfully. The pattern ^234 will not, because the caret ^ constrains the matching to occur at the start of the input string, and ours does not start with 234 (the pattern ^123 will of course succeed). Similarly in the pattern 234$, the dollar $ constrains the matching to occur at the end of the input string, and so this will also fail to match our input, whereas 345$ will succeed. Finally, using both assertions, ^12345$ will match only the entire input string 12345, while any other sub-pattern such as ^1234$ fails.

These two meta characters are examples of atomic zero-width assertions, also known as anchors. Zero-width means that they do not cause the engine to advance through the string or consume characters; they just assert something about the current position in the input. There are several other anchors, but now I want to turn to more general assertions.

Assertion Types

Both of the above examples can be characterised as positive assertions, in that they require something to be true about the current position; namely that it is the start, or end, of the line. You could imagine another assertion type, where you want to match a particular sequence anywhere except either or both of those positions. And yes, such negative assertions are available, as we'll soon see.

Another characteristic of assertions is the direction they face. The caret ^ is termed a look-behind assertion; it states that no input exists before the current position. Similarly the dollar $ is termed look-ahead, as it states there's no further input available beyond the current position.

Finally, the new assertions I'm about to introduce, while still zero-width, are no longer atomic. Instead of referring to known fixed points, such as the beginning or end of the string, line, previous match, or word/non-word boundary, these new assertions contain their own independent subexpression patterns, which they assert do (or do not) occur immediately before (or after) the current position in the input. The parentheses here reflect the difference between positive and negative assertions, and between look-behind and look-ahead behaviour. So there have to be four types, right?

They all use syntax similar to grouping constructs. Positive assertions are indicated by =, negative by !. By default these are assumed to be look-ahead, unless prefixed by < to signify look-behind.
positive look-ahead: (?= subexpression)
negative look-ahead: (?! subexpression)
positive look-behind: (?<= subexpression) ◀ this is the one we are going to use
negative look-behind: (?<! subexpression)
Back To Highlighting

Refer to MSDN for examples of each of these. Now I just want to finish by showing how a zero-width positive look-behind assertion can be used to protect the content of those HTML tags.

How can we write a pattern to match search terms ignoring tag contents? If we're inside a tag, then there's a < somewhere to our left, as yet unmatched by a closing >, while if we're outside, then either there are no < on the left, or else every such < is matched by a corresponding > also on our left. In other words, we want everything on our left to consist of: start of line ^, followed by any number of (a) non-< characters, or else (b) < characters with eventual matching > characters:
^([^<]|<[^>]*>)*
Finally, wrap that as the subexpression in the third template above, and we're done:
(?<=^([^<]|<[^>]*>)*)
Code Sample
private static string Highlight(string input, string search, string cssClassName)

{

  const string assertion = "(?<=^([^<]|<[^>]*>)*)";

  var pattern = string.Format("{0}{1}", assertion, search);

  return Regex.Replace(

      input,

      pattern,

      match => string.Format("<span class=\"{0}\">{1}</span>", cssClassName, match.Value));

}



private static string Test()

{

  return Highlight(

      "<span class=\"ignorethisclass\">This</span> is the class.",

      "class",

      "highlight");

}



// Output: <span class="ignorethisclass">This</span> is the <span class="highlight">class</span>.

Disclaimer

Remember, this is only an illustrative example. As a practical HTML postprocessing solution, there's still a number of holes in it!

Tuesday 2 August 2011

Ten Visitors

Featuring: A Litter of Bichon Frise

Sounds like a wine order to me! "Waiter, if you would send to my table, a carafe of Pinot Noir. Yes, and a litter of Bichon Frise, thank you."



Half a dozen of the little Water Spaniel / Standard Poodle descendants, who came visiting last night. They brought their parents, Pepi and Popi. And they brought their owners, our friends Bojan and Theresa.

At no point did Linda consider, even for a second, keeping any of them - as you can clearly see from her picture:



No, not even the one she'd picked out and decided to name "Number Five":



If anything my own resolve was tougher still. No way did I want to keep one of these...



...never mind two...



...and least of all, erm, three...



All too soon, the pups had to be packed away again...



I do hope that they will all find excellent homes. But not before they've visited us again!

Monday 1 August 2011

Tweets - July 2011