Posts Tagged ‘security’

VMware update insecurity

April 16, 2013

So the good news is VMware has a built in updater, and even better the server it uses to query for information is SSL/TLS enabled. The bad news is they are using Akamai with an insecure configuration: vmware-update-overall-grade A quick note: Akamai is a huge content delivery network (CDN) used by many vendors to deliver content and software updates to end customers. Some pretty insecure configurations of SSL and TLS are supported by Akamai for the simple fact that there is still a lot of old software/clients out there, which Akamai’s customers want to support. As you can see here if you query they use an Akamai certificate: vmware-update-akamai Nothing wrong so far, but when you look at the versions of the SSL protocol that are supported they have left SSL 2.0 enabled, and they have also left weak ciphers including several 40 bit ones enabled: vmware-update-weak-ciphers This makes an SSL downgrade attack trivial for an attacker as 40 bit keys can be broken in near real time now with even a remotely powerful computer that has a GPU.  Using this an attacker can man in the middle your upgrade session and tell the client no updates are available (forcing you to remain on an older version with security issues), or potentially send you a malicious update. I haven’t looked at the guts of the VMware updater, for all I know they may use additional protections like secure signing of the update software itself, but let’s hope they do, because the communication channels it is sent over are not very secure. The good news is that fixing this is easy, VMware just needs to make sure their updater software supports TLS and secure ciphers (which if they’re using an even moderately up to date library won’t be a problem), and they need to update their Akamai configuration to exclude SSL 2.0 and the weak ciphers.

How not to post log information, or why I shred every piece of paper I touch

July 4, 2012

So this thread just came to my attention:

I use postfix2.5.5 rpm to run postfix as relay server
since from last many day my application team of SAP software started complaining for the smtp email failuer
pls find the below longs

Email 1

Feb  6 10:41:22 D1SNX682RL postfix/smtpd[3693]: connect from unknown[]
Feb  6 10:41:23 D1SNX682RL postfix/smtpd[3693]: 20C453E00C0: client=unknown[]
Feb  6 10:41:23 D1SNX682RL postfix/cleanup[10313]: 20C453E00C0: warning: header Subject: RE: RE: RE: RE: RE:// FOLLOW UP // HBL SCREENSHOT //  FINAL SI & HBL // E.R FREMANTLE 087 // HIBLOW from unknown[]; from=<MANILA_DOCS <at> APL.COM> to=<crm_email_archive_apl <at>> proto=ESMTP helo=<>
Feb  6 10:41:23 D1SNX682RL postfix/cleanup[10313]: 20C453E00C0: message-id=<ADR37000000104995 <at>>
Feb  6 10:44:27 D1SNX682RL postfix/smtpd[3693]: lost connection after DATA (437492 bytes) from unknown[]
Feb  6 10:44:27 D1SNX682RL postfix/smtpd[3693]: disconnect from unknown[]

Followed by:

please at least remove from this site , there is security audit going on in my organisation i dont want to maintain this thread , please remove this .

Whoops. You may have noticed in my previous posting “Fedora 16 and Red Hat on EC2 with Sendmail using SMART_HOST with authentication” I took the time to sanitize all the IPs and hostnames presented in the examples. It was a bit of a chorse (running search and replace is simple, but reading the results three times to ensure nothing was missed is tedious), but it’s worth it. Would the information aid an attacker? A little bit. There are other ways to find this out as well (error messages from servers, etc.).

But the reason I do it is simple: if you ALWAYS sanitize information then you won’t run into a situation where you decided not to sanitize the information and later turned out to be wrong. This is exactly why I shred every single piece of paper I touch before throwing it out. Do I need to shred the envelopes my bills come in? They have no personal information/etc., they could conceivably be used to determine which banks/companies I deal with, and how much I deal with them, but I’m not overly worried about that (anyone taking the time to go through all my trash can find this out other ways). No the reason I shred everything, including envelopes is so that I never have to worry about throwing something away sensitive. Also I don’t have to spend any time/effort deciding if something needs shredding or not, it all automatically goes into a pile, and when I’m bored I feed the shredder (I actually find it oddly fun…).

Creating temporary files securely

March 14, 2012

Creating temporary files  is a common use case in virtually every program. Virtually every programming language has a simple and secure way to create temporary files. Sadly many programmers fail to use them, creating security vulnerabilities in their applications. So in alphabetical order here is a list of programming languages and how to create a temporary file securely. If I’m wrong, please let me know. Note: when searching for a secure temporary file creation function/method/etc. looking for “mkstemp” is a quick way to find most of them. Please note a lot of sites (e.g. contain old/wrong information.

O_CREAT and O_EXCL (and similar)

When opening a temporary file in C you MUST use O_CREAT and O_EXCL together to ensure that the file is only created if the file does not exist. Otherwise between the time you check for the existence of a file and the time you create the file an attacker may be able to create a file with the same name. The good news here is that virtually every secure temporary file creation function/library does this or an equivalent option. To quote mkstemp():

The mkstemp() function shall replace the contents of the string pointed to by template by a unique filename, and return a file descriptor for the file open for reading and writing. The function thus prevents any possible race condition between testing whether the file exists and opening it for use.

Why “unique” names are not enough, but are generally not a huge problem

People often think that creating a file with a “unique” name in /tmp (e.g. “/tmp/myprogram-output.log”) is sufficient to safely create a temporary file. However if you create the file with a known or easily guessed name (e.g. a static name set in the source code or a config file) an attacker can create the file first and then your application will be unable to, creating a denial of service condition potentially.

However the names don’t have to be terribly unique. For example if you use mkstemp() with 10 random characters (the default) gives on the order of 839,299,365,868,340,224 possible file names. Any attacker able to create enough files to force a collision of the name would be able to fill up the /tmp directory in any event (unless you have an absurdly large /tmp directory that is several exabytes in size, which won’t be a problem for some time).

Unexpected temporary files

It should also be noted that many programs create temporary files. Text editors and other file editors may create temporary file saves in /tmp or /var/tmp and so on.

The problem with $TMP, $TEMP, $TMPDIR, $TEMPDIR and so on

One note: if you’re going to use environmental variables you’d better make sure you sanitize them and ensure they aren’t overly long. User controlled environmental variables are just that, user controlled. I can’t find a good set of libraries or code to sanitize these variables before use, if anyone knows of such a thing please contact me ([email protected]).

Better list for lots of other languages:

Please see


Simply use “mktemp” (“man mktemp” for details). Use “-d” or “–directory” for creating directories.


use mkstemp() (“man mkstemp” for details) for files

use mkdtemp() (“man mkdtemp” for details) for directories

tmpfile() is another option – Creates a temporary binary file, open for update (wb+ mode — see fopen for details). The filename is guaranteed to be different from any other existing file.


use mkstemp() (“man mkstemp” for details)

use mkdtemp() (“man mkdtemp” for details) for directories

tmpfile() is another option – Creates a temporary binary file, open for update (wb+ mode — see fopen for details). The filename is guaranteed to be different from any other existing file.

On Windows use GetTempPath() and GetTempFileName () (same names in C#)




Google Go (golang)

So ioutil.TempDir and ioutil.TempFile automatically appends a uint32 and has default permissions of 0600. Well done.

Use this and you’re safe. Just a note: io.TempDir returns the value of the temporary directly (e.g. /tmp).


use – some interesting info at

for directories there is a helpful posting at

Java 7

for files use

for directories use createTempDirectory()




use mkstemp()


Simply use “mkstemp” for files and “mkdtemp” for directories from the “tempfile” module:


use QTemporaryFile for files:

use  for QTemporaryDir directories:


use Tempfile for files:

use tmpdir for directories (require ‘tmpdir’ and then you can “Dir.mktmpdir”):

Making per user /tmp directories

Using PAM you can also make per user /tmp directories using polyinstantiation

If you have a system with many users (e.g. a shell server or web host) this is a great way to avoid the whole /tmp mess at the system level rather than trying to ensure your applications are properly written.

Monitoring /tmp for activity

So how can we be sure our changes work and temporary directories and files are being created safely? Conversely how can we monitor /tmp to watch for programs that use /tmp improperly or in unsafe ways? Linux has an inotify subsystem that allows you to monitor a file(s) or directory(s) (including recursively) for file and directory related activity (creation, deletion, modification, etc.). The downside of inotify is that, as far as I can tell, there is no way to list which process was responsible (so if you have a large application and multiple applications running it may be difficult to track down which one specifically created the file/etc.

To use inotify use either the “inotify-tools” or “pyinotify” programs, I prefer pynitofy, the output is really easy to read:

# /usr/bin/pyinotify /tmp/
<Event dir=True mask=0x40000100 maskname=IN_CREATE|IN_ISDIR \
name=foo.ooCHP2tb1adt path=/tmp pathname=/tmp/foo.ooCHP2tb1adt wd=1 >

You can also use SELinux, running permissive mode simply disable all access to /tmp and then run your application(s). The log files will show any accesses of /tmp including the process information.

Auditing for /tmp file vulnerabilities

It’s not hard, mostly I just do:

find ./ -type f -exec grep /tmp {} +

and if they wrote the code using the above techniques it is probably safe, if it is written any other way it’s probably wrong.

Which directory should you use?

You should be using /var/run/something/ or /run/something/ that is setup in advance and secured for the users/groups that require it.

Spotting counterfeit money

April 22, 2010

It’s about time but Canada will be moving to a plastic/polymer bill based instead of paper/linen based bills in 2011 or so. Back in 2004 counterfeit bills peaked (“The prevalence of counterfeiting in Canada and its impact on direct victims and society“) and prior to that the majority of it was $50 and $100 bills being counterfeited by one guy (Wesley Weber) who managed to put enough fake $100 bills into circulation that even now in 2010 most retailers won’t accept $100 bills.

Probably the easiest way to defeat counterfeiters is the move to plastic/polymer notes, this is a combination of the ease of checking the bills (the feel/etc. will be entirely different than current notes, even in a dark nightclub a waitress should be able to tell the difference) and the difficulty in getting the stock and printing on it (at least for now….). I remember one local store that had a counterfeit %40 pinned to the wall, it was literally 20 lb copier paper printed in an ink jet and looked more like monopoly money than real currency (the reds were saturated and bloby).

But in the meantime we’ll have to stick to the old fashioned methods of checking currency (security strip embedded in the paper, micro print, reflective metal patch, etc.). For more information on the Canadian security features see the Bank of Canada page and for American money check out (way higher production values!).

One thing you will note is a common and consistent set of features used to prevent counterfeiting of banknotes:

  • embedded metal strip in the printing stock with the value of the bill printed on the strip (prevent people from running these off on a copier or bleaching a $20 bill and reprinting it as a $100 bill)
  • metal reflective patches that refract light differently depending on the angle you view it at (like a soap bubble)
  • micro print, and lots of it (in the background, in the numbers, on the faces, etc.)
  • raised ink (and embedded braille dots for the blind)
  • water marks (printing embedded in the paper as opposed to on the paper)
  • UV fluorescence under black light
  • iodine pens, since bills are mostly linen and not paper iodine doesn’t mark the bill significantly

Hopefully this will inspire and encourage web browsers and other software makers to come up with a common set of features to help users identify the legitimacy of online web sites (my next post).

Verisign certificate authority finally fixes (part of the) domain verification problem

April 20, 2010

So a few months ago I decided to see how easy it was to buy an SSL certificate for a domain I didn’t own. It turns out that it was very easy because at least one large certificate authority (CA), RapidSSL (owned by Verisign) allowed a large number of email addresses to be used for verification (such as [email protected], [email protected], etc.).

The original article is available here: I also contacted the Mozilla/Firefox people through the mailing list to let them know about it and to show the proof (the emails from RapidSSL to me). Betanews ran a nice article (, and not much else happened for a while.

Things finally got rolling when a Bugzilla report was filed (Bug 556468, which was basically a copy of an older bug Bug 477783 concerning Equifax doing basically the same thing). A Verisign representative confirmed they had removed a bunch of problematic email addresses they allowed, but [email protected] was still valid (this turned out to be a mistake as you’ll soon see).

Fast forward about two weeks and someone has copied my article and thrown in a few screen shots and submitted it to Slashdot ( personally I don’t mind if people copy my work and build off of it, but when they protray it as their own original work with no credit or original source mentioned that is a bit annoying.

Although annoying it had the benefit of showing the world that by using the [email protected] email address (remember, the one Verisign didn’t remove) which resulted in the rather quick disabling of it:

VeriSign will be removing the following generic approver email options for GeoTrust and RapidSSL as of tonight or tomorrow night:

– ssladmin, sysadmin, and info

So I guess in the end it worked, certificates are hopefully a little more secure now but the sad thing is I spent several dozen hours basically holding vendors feet to the fire for something they should have been doing all along.

Oh and there is no way to find out if a certificate authority has issued a certificate for your domain to someone else. Unlike DNS/etc. there is no way to query what certificates have been issued.