Tuesday, 13 March 2018

Great Rack Mount Mistakes #6

A long time coming, here's another story from my days long past, this one takes me to my very first serious role in an IT department, I was however just the dogs body.  The company ran many old PC's (which I actually was around to see mostly be updated to nice Compaq Pentium III's) and they had a couple of high spec Silicon Graphics workstations in the design department.

The main manufacturing control and purchasing system, as well as payroll and a bunch of other services ran on a dual 386 based mini computer, which had a custom cut of ScoUnix and a bunch of bespoke C programs comprising the actual system stack, this was accessed by a whole host or Gandalf multiplexers combining the serial connections down from a hundred or so Wyse brand terminals (I wish I'd have nabbed one of those before I left).

Anyway, it was time for this back end stack to be updated, and so a pair of Compaq Proliant servers were brought in, these were dual Pentium III class with a dedicated storage unit and a large; and importantly heavy; UPS unit.

The problem?  The IT manager I worked for (Hi Dave) didn't get on at all well with the manager at the co-location this unit was to be installed in.  Therefore in a dual effort to maintain any vestige of control and avoid the guy he didn't like, my boss ordered all the equipment to be delivered to our office... In central Nottinghamshire.... Yet its final destination once configured was to be outside Peterlee in the North East, near Newcastle.

So after around a day of setting up the equipment and (as far as I recall) three days solid compiling time - yes it took that long - the system was ready to go.

However, no-one had kept the boxes, yes it was all out of the box spread on a floor and then hand hauled over to a fire-exit and precariously piled into the back of a Hyundai estate.

Yes, that's how tens of thousands upon thousands of pounds worth of top notch equipment (for 1998) made it's precarious way 120 miles, bouncing and jostling all the way.

At the time I never questioned this, I was a lowly minion, I would of course council against such a move ever again, the installation of the physical equipment should have been done at the remote site, and they definitely should have kept the boxes and packaging in full!

Thursday, 8 March 2018

Sex, Secret or God... Passwords

In the 1990's it was common to have to tell folks not to use "popular" password, like "sex", or "god", believe it or not even "password" and "secret".  Since then times have moved on, folks have become very adept at using other characters in their passwords...

Unfortunately, this is (very seriously) what one of our IT bods here has just found on a machine:

Props to the user for mixing in some numbers, a word and a symbol, however... We can all see the flaw in their storing the password.

(Thanks to our IT Manager for letting me use his picture - it is a lovely left hand, I wonder if he does hand modelling?)

Tuesday, 6 March 2018

KitKat Still Broken....

No, I'm not talking about any build of Android, I mean the actual chocolate bar...

Having my first one since June last year...  Still broken.

Tuesday, 27 February 2018

"Zeiger" The Missing C Type Link

I'm just looking at an old C Compiler, the first C compiler I ever used, actually... And, I'll be honest, I didn't live with C long, I moved into C++ pretty quickly.  So much so, I never actually read the this C Compiler's Documentation, here for posterity, is an exert...

Pre-defined Data Types

      Type        sizeof      Bits            Range
      ----        ------      ----            -----
  unsigned char      1          8             0 to 255
  char               1          8          -128 to 127
  enum               2         16        -32768 to 32767
  unsigned short     2         16             0 to 65535
  short              2         16        -32768 to 32767
  unsigned int       2         16             0 to 65535
  int                2         16        -32768 to 32767
  unsigned long      4         32             0 to 4294967295
  long               4         32   -2147483648 to 2147483647
  <pointer>          4         32
  float              4         32   (+-)3.4E-38 to (+-)3.4E+38
  double            10         80 (+-)3.3E-4932 to (+-)1.2E+4932
  long double       10         80 (+-)3.3E-4932 to (+-)1.2E+4932
  Zeiger             4         32             0 to 4294967295

I have never heard of the "Zeiger" type, it's simply an unsigned 32 bit integer, but where does that name come from?

It's a German word, meaning pointer or hand, so I can only assume it's a pointer to some memory location and the machine this compiler is for, if I recall correctly had a 4 megabyte maximum address space, plus 64K of addressable ROM.  So a Zeiger would be useful to parse over any location in both, however it's not clearly stated in the information.

Zeiger is a reserved word in this compiler, and yet it purports to be ANSI compliant... Hmmm.... Thoughts as ever in the comments below.

Sunday, 25 February 2018

C++14 std::memset Not Working?

When I say not working, I do not mean the function does not work, of course it works.  What I mean is that left to it's on devices the GCC compiler can actually chose to not perform a memset in certain circumstances, you can read more detail about this in the official bug list.

So, what's going on?  Well, I have a piece of code which uses a common buffer, each function locks a mutex (std::lock_guard), fills out the buffer and then transmits over USB to target devices, crucially I then want to clear the common buffer.

The purpose of this architecture is to keep sensitive information being transmitted through the buffer present for as little time as possible (i.e. the time between filling out and transmit, ~35ms) rather than filling out, transmitting and leaving the data in the buffer; as the time between calls may be anything up to 5 seconds, plenty of time for someone to halt the program and inspect memory dispositions.

In pseudo code therefore our sequence looks something like this:


    std::memset(BUFFER, 0, 256);

In debug this worked no problems, all my soak testing worked, I was quite happy.

Until one switches to release, whereupon the GCC compiler can opt to optimise away calls which it defines as not having any noticeable effect.

In the case of the memset call here, to the compiler, locally sees nothing inspect the BUFFER variable after the memset is performed, it therefore decides nothing is bothered the buffer is cleared or not.

Of course we know the next call to any call, or the same call, will rely on the BUFFER being empty when it enters.

There are therefore two problems, if one had this code:

    std::memset(BUFFER, 0, 250);
    std::memset(BUFFER, 0, 256);

You would of course pass all your tests, even in release, the buffer would work as expected, you could even assume no data is being left in RAM between transmit calls; you'd be dead wrong, but you can assume anything you like really.  No, what's happening here of course is that the lead-in memset is clearing the buffer before use, but the sensitive data is left in the buffer between calls as the latter memset is still being optimised away.

The code remains vulnerable to introspective intrusion attempts.

The real solution?  Well, I've gone with:

    std::memset(BUFFER, 0, 250);
    std::memset(BUFFER, 0, 256);
    auto l_temp(buffer[0]);
    buffer[0] = buffer[1]
    buffer[0] = l_temp;

Whatever you do to solve this, don't spend a whole day as I just have.

In conclusion, of course the call works, it's the compiler which is optimising the call away.

Saturday, 24 February 2018

WD Disk DOE & Dust....

I recently ordered a new WD Blue disk, it duly arrived and had the strangest problem I've seen in many a long year, no matter what I did the disk showed as 64MB total and it lost all data upon power cycling.

I puzzled over this briefly, until I pulled the disk back out the caddy and saw it had exactly 64MB of cache, yes, no platter space was being shown, just the cache showing up as disk space.  I have never ever seen this before, cache has always been a transparent intermediary for me in production and so to suddenly have the cache being the only exposed space was odd.

However, dead on arrival hard disk, a quick RMA and a new one winged its way into my hands, they actually gave me a slight upgrade as I got a WD Black by return of post.

Tonight I planned an hour to fit the new disk and add it to my workstation.... This machine has no cable management, and its a nightmare to add drives, there are six built in 3.5" bays but they have a set latch and screw mechanism, which forces you to fit the drives to that the power connectors are actually straining the distant power plugs. (I do plan to buy a pair of SATA power extenders on pay day).

What struck me as a massive problem however, is the amount of dust inside there.  Clearly, since fitting the 1080 GTX I've had something change or fail or open as there are copious amounts of dust in there.

Now my work area is not optimum for a workstation, I have a full tower case, so it has to go under the desk and the floor is carpeted.  Now this had been mitigated by the Coolmaster Cosmos 1000 case having lifting rails, taking the whole thing 1.25" off of the floor level, and two ground level filters, as well as a rear and front filter set.

But clearly things have not gone well, as just dust dust dust.

My original plan for the start of the year was to re-case the server, then re-case this PC as a server as well, retire one of the aging DELL 2950's for this machine itself, and put myself a new workstation together for my 40th.

Trouble is?... I'm skint, like proper skint, so I can't afford the workstation I was planning on...

And now I need to sort out this machine... I smell another re-casing task a head... Hmm, which case?  I'm thinking about the Corsair Obsidian range... Anyone have any other suggestions for a full height tower?... 1 x 5.25" at least 6 x 3.5" internal mount points and at least 2 x 2.5" mount points internally.  Front Panel USB would be a boon.

Dust seems to be my enemy.

Tuesday, 13 February 2018

Windows : Com File Effect

I'll never claim to know everything about Linux nor Windows, I know a lot more about the former than the latter, mainly as the Windows is a closed source product.  As such it doesn't get my attention as much, unless something is going wrong.... Today I have found an effect I can't explain (at least not easily) in windows, clearly it's some sort of reserved file name or type effect.... Maybe you can explain this to me.

So, open any folder, right click and go to create a new text file...

Once you have the file...

Change the name to "COM" and a port number, so "COM1" in my case.... It can be any COM port name, even if you don't have that port installed or active on your machine....

Once you complete the name, or change focus of the text entry (by say taking a screen shot - not actually committing the new file to disk) you get this strange message...

"The Specified device name is invalid"....

What device?  I'm trying to create a filename.  I was immediately a little puzzled, I've used Windows since Windows 2.0  I've never ran into this issue.

Googling around I find a chap on social.technet.microsoft.com saying not to use a whole plethora of names for files or folder as they're reserved, I have never heard of this.

The official Microsoft advice likewise says not to use these values, and it kindled a memory in me from programming in DOS 6 back in the mid 90's, one would in Pascal, you could "println(PRN, 'some message');" and see the message print out on the printer.

I find it amazingly odd that these files are still reserved in 2018, they're proper nouns, they're things you may want to name files, and they have a FULL Path, which makes them very distinct than the COM port device.  Its odd, trust me.

But the oddest thing is, what does Windows do, what is the piece of code picked up and made to run that message box upon creation of the file?  And I've got to wonder how exploitable that maybe in local malware to open lots of message boxes and annoy the user.