Anonymous sends us this little blob of code, which is mildly embarassing on its own:
static StringBuilder vsb = new StringBuilder();
internal static string IsValidUrl(string value)
{
if (value == null)
{
return "\"\"";
}
vsb.Length= 0;
vsb.Append("@\"");
for (int i=0; i<value.Length; i++)
{
if (value[i] == '\"')
vsb.Append("\"\"");
else
vsb.Append(value[i]);
}
vsb.Append("\"");
return vsb.ToString();
}
I’m willing to grant that re-using the same static StringBuilder
object is a performance tuning thing, but everything else about this is… just plain puzzling.
The method is named IsValidUrl
, but it returns a string. It doesn’t do any validation! All it appears to do is take any arbitrary string and return that string wrapped as if it were a valid C# string literal. At best, this method is horridly misnamed, but if its purpose is to truly generate valid C# strings, it has a potential bug: it doesn’t handle new-lines. Now, I’m sure that won’t be a problem that comes back up before the end of this article.
The code, taken on its own, is just bad. But when placed into context, it gets worse. This isn’t just code. It’s part of .NET’s System.Runtime.Remoting package. Still, I know, you’re saying to yourself, ‘In all the millions of lines in .NET, this is really the worst you’ve come up with?’
Well, it comes up because remember that bug with new-lines? Well, guess what. That exact flaw was a zero-day that allowed code execution… in RTF files.
Now, skim through some of the other code in wsdlparser.cs
, and you'll see the real horror. This entire file has one key job: generating a class capable of parsing data according to an input WSDL file… by using string concatenation.
The real WTF is the fact that you can embed SOAP links in RTF files and Word will attempt to use them, thus running the WSDL parser against the input data. This is code that’s a little bad, used badly, creating an exploited zero-day.