I frequently write bad code. I mean, we all do, but I frequently write bad code with full knowledge that it's bad, because I first want to test out an idea. Or, I want to inject some additional behavior just for one run, because I'm trying to debug something. If that idea or debugging hook turns out to be valuable, I'll frequently refactor it into something useful and enable it via a flag or something.
Which brings us to the crash Doug was investigating in a VB.Net application. For some reason, the username field was an empty string after logging in, and a bunch of methods which expected the username to have a value misbehaved after that.
Well, one of the debugging hooks was turned on, and it called GetReplacementUser
, which… is interesting.
'Similar to the Debug class, hard coded items in this function are intentional.
'
Private Shared Function GetReplacementUser() As String
Dim line As String
Dim userName As String = String.Empty
Try
Using sr As System.IO.StreamReader = New System.IO.StreamReader("C:\Temp Files\DeleteThisfile.txt")
line = sr.ReadLine
If line.Contains(My.User.Name) Then
userName = line.Split("-"c)(3)
End If
End Using
Catch ex As Exception
End Try
Return userName
End Function
I'm a little afraid about what might be going on over in the Debug
class, but this is the one we have in front of us, so let's dig in. The goal, I suspect, is to allow the user running the program to impersonate another user, hopefully not in production, but let's be realistic- it probably could be used that way.
Regardless, the way that we do this impersonation is by reading a file name C:\TempFiles\DeleteThisFile.txt
. If the first line of that file contains My.User.Name
- a convenient accessor for your OS-level logged in user- then we split the line and take the fourth field in it and use that as the username. So, during debugging, by writing a character-separated file, where the fourth field in the first line is someone's user name, you can impersonate that user. But, if the file doesn't exist, or the first line doesn't contain your user name, the userName
field is returned as an empty string.
The bad choices were intentional, as the comment says, but I'm not sure the developer responsible knew they were bad choices. Or maybe the believed that intentionally bad choices are actually good, because you meant to do that.
Fixing the crash issue was easy for Doug- just disabled those hooks. Picking apart all the weird and dangerous bits of debug-hackery in there, however, was a much larger effort.