Wednesday, June 13, 2018

The Manager Who Knew Everything

Have you ever worked for/with a manager that knows everything about everything? You know the sort; no matter what the issue, they stubbornly have an answer. It might be wrong, but they have an answer, and no amount of reason, intelligent thought, common sense or hand puppets will make them understand. For those occasions, you need to resort to a metaphorical clue-bat.

A few decades ago, I worked for a place that had a chief security officer who knew everything there was to know about securing their systems. Nothing could get past the policies she had put in place. Nobody could ever come up with any mechanism that could bypass her concrete walls, blockades and insurmountable defenses.

One day, she held an interdepartmental meeting to announce her brand spanking shiny new policies regarding this new-fangled email that everyone seemed to want to use. It would prevent unauthorized access, so only official emails sent by official individuals could be sent through her now-secured email servers.

I pointed out that email servers could only be secured to a point, because they had to have an open port to which email clients running on any internal computer could connect. As long as the port was open, anyone with internal access and nefarious intent could spoof a legitimate authorized email address and send a spoofed email.

She was incensed and informed me (and the group) that she knew more than all of us (together) about security, and that there was absolutely no way that could ever happen. I told her that I had some background in military security, and that I might know something that she didn't.

At this point, if she was smart, she would have asked me to explain. If she already handled the case, then I'd have to shut up. If she didn't handle the case, then she'd learn something, AND the system could be made more secure. She was not smart; she publicly called my bluff.

I announced that I accepted the challenge, and that I was going to use my work PC to send an email - from her - to the entire firm (using the restricted blast-to-all email address, which I would not normally be able to access as myself). In the email, I would explain that it was a spoof, and if they were seeing it, then the so-called impenetrable security might be somewhat less secure than she proselytized. In fact, I would do it in such a way that there would be absolutely no way to prove that I did it (other than my admission in the email).

She said that if I did that, that I'd be fired. I responded that 1) if the system was as secure as she thought, that there'd be nothing to fire me for, and 2) if they could prove that it was me, and tell me how I did it (aside from my admission that I had done it), that I would resign. But if not, then she had to stop the holier-than-thou act.

Fifteen minutes later, I went back to my desk, logged into my work PC using the guest account, wrote a 20 line Cold Fusion script to attach to the email server on port 25, and filled out the fields as though it was coming from her email client. Since she had legitimate access to the firm-wide email blast address, the email server allowed it. Then I sent it. Then I secure-erased the local system event and assorted other logs, as well as editor/browser/Cold Fusion/server caches, etc. that would show what I did. Finally, I did a cold boot to ensure that even the RAM was wiped out.

Not long after that, her minions the SA's showed up at my desk joking that they couldn't believe that I had actually done it. I told them that I had wiped out all the logs where they'd look, the actual script that did it, and the disk space that all of the above had occupied. Although they knew the IP address of the PC from which the request came, they agreed that without those files, there was no way they could prove that it was me. Then they checked everything and verified what I told them.

This info made its way back up the chain until the SAs, me and my boss got called into her office, along with a C-level manager. Everything was explained to the C-manager. She was expecting him to fire me.

He simply looked at me and raised an eyebrow. I responded that I spent all of ten minutes doing it in direct response to her assertion that it was un-doable, and that I had announced my intentions to expose the vulnerability - to her - in front of everyone - in advance.

He chose to tell her that maybe she needed to accept that she doesn't know quite as much about everything as she thinks, and that she might want to listen to people a little more. She then pointed out that I had proven that email was totally insecure and that it should be banned completely (this was at the point where the business had mostly moved to email). I pointed out that I had worked there for many years, had no destructive tendencies, that I was only exposing a potential gap in security, and would not do it again. The SAs also pointed out that the stunt, though it proved the point, was harmless. They also mentioned that nobody else at the firm had access to Cold Fusion. I didn't think it helpful to mention that not just Cold Fusion, but any programming language could be used to connect to port 25 and do the same thing, and so didn't. She huffed and puffed, but had no credibility at that point.

After that, my boss and I bought the SAs burgers and beer.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!


To read the full article, please visit The Daily WTF

Tuesday, June 12, 2018

CodeSOD: Maximum Performance

There is some code, that at first glance, doesn’t seem great, but doesn’t leap out as a WTF. Stephe sends one such block.

double SomeClass::getMaxKeyValue(std::vector<double> list)
{
    double max = 0;
    for (int i = 0; i < list.size(); i++) {
        if (list[i] > max) {
            max = list[i];
        }
    }
    return max;
}

This isn’t great code. Naming a vector-type variable list is itself pretty confusing, the parameter should be marked as const to cut down on copy operations, and there’s an obvious potential bug: what happens if the input is nothing but negative values? You’ll incorrectly return 0, every time.

Still, this code, taken on its own, isn’t a WTF. We need more background.

First off, what this code doesn’t tell you is that we’re looking at a case of the parallel arrays anti-pattern. The list parameter might be something different depending on which key is being searched. As you can imagine, this creates spaghettified, difficult to maintain code. Code that performed terribly. Really terribly. Like “it must have crashed, no wait, no, the screen updated, no wait it crashed again, wait, it’s…” terrible.

Why was it so terrible? Well, for starters, the inputs to getMaxKeyValue were often arrays containing millions of elements. This method was called hundreds of times throughout the code, mostly inside of window redrawing code. All of that adds up to a craptacular application, but there’s one last, very important detail which brings this up to full WTF:

The inputs were already sorted in ascending order.

With a few minor changes, like taking advantage of the sorted vectors, Stephe to the 0.03333 frames-per-second performance up to something acceptable.

[Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!


To read the full article, please visit The Daily WTF

Monday, June 11, 2018

CodeSOD: The Enabler

Shaneka works on software for an embedded device for a very demanding client. In previous iterations of the software, the client had made their own modifications to the device's code, and demanded they be incorporated. Over the years, more and more of the code came from the client, until the day when the client decided it was too much effort to maintain the ball of mud and just started demanding features.

One specific feature was a new requirement for turning the display on and off. Shaneka attempted to implement the feature, and it didn't work. No matter what she did, once they turned the display off, they simply couldn't turn it back on without restarting the whole system.

She dug into the code, and found the method to enable the display was implemented like this:

/***************************************************************************//**
* @brief  Method, which enables display
*
* @param  true = turn on / false = turn off
* @return None
*******************************************************************************/
void InformationDisplay::Enable(bool state)
{
  displayEnabled = state;
  if (!displayEnabled) {
    enableDisplay(false);
  }
}

The Enable method does a great job at turning off the display, but not so great a job turning it back on, no matter what the comments say. The simple fix would be to just pass the state parameter to enableDisplay directly, but huge swathes of the code depended on this method having the incorrect behavior. Shaneka instead updated the documentation for this method and wrote a new method which behaved correctly.

As you can guess, this is one of the pieces of code which came from the client.

[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.


To read the full article, please visit The Daily WTF

Friday, June 8, 2018

Error'd: Try Again (but with More Errors)

"Sorry, Walgreens, in the future, I'll try to make an error next time," Greg L. writes.

 

"Hmm, I'm either going to shave with my new razors that I ordered... or I won't," wrote Paul.

 

Charlie L. writes,"IFNAME would be my name, IF it were my name that is."

 

"Yep, Dell, I like to brag about my kids File, Edit, View, Tools, and Help," wrote Carl C.

 

Renato L. writes, "Low-cost airlines have come a long way. Forget the Gregorian calendar, created their own one."

 

"So is this becuase, somehow, passwords longer than 9 characters are less secure?" wrote Keith H.

 

[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.


To read the full article, please visit The Daily WTF

Thursday, June 7, 2018

Improv for Programmers: The Internet of Really Bad Things

Things might get a little dark in the season (series?) finale of Improv for Programmers, brought to you by Raygun. Remy, Erin, CiarĂ¡n and Josh are back, and not only is everything you're about to hear entirely made up on the spot: everything you hear will be a plot point in the next season of Mr. Robot.

Raygun provides a window into how users are really experiencing your software applications.

Unlike traditional logging, Raygun silently monitors applications for issues affecting end users in production, then allows teams to pinpoint the root cause behind a problem with greater speed and accuracy by providing detailed diagnostic information for developers. Raygun makes fixing issues 1000x faster than traditional debugging methods using logs and incomplete information.

Now’s the time to sign up. In a few minutes, you can have a build of your app with Raygun integrated, and you’ll be surprised at how many issues it can identify. There’s nothing to lose with a 14-day free trial, and there are pricing options available that fit any team size.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!


To read the full article, please visit The Daily WTF