Secure64 Is Not Vulnerable To Log4j

Secure64 has validated that the Log4j flaw, also known as the Log4shell vulnerability, is NOT a threat to the Secure64 suite of products

Not Vulnerable – Intel Itanium/Secure64 SourceT

Intel Itanium and Secure64 Source T are NOT vulnerable to either Spectre or Meltdown and below are explanations of how both vulnerabilities work, and why Itanium and SourceT are immune.

by John Worley, Director of Engineering, Secure64

The newly announced vulnerabilities (CVE-2017-5715, CVE-2017-5753, CVE-2017-5754) code named Spectre and Meltdown have sent shivers and shockwaves through the open-source and enterprise communities. Rather than just a simple software flaw, the vulnerabilities are at the heart of almost every computing system in the world today: the CPU.

Both Spectre and Meltdown exploit flaws in the implementation of the tremendously complex internal hardware working to provide the appearance of a continuous stream of parallel instruction execution.


Spectre, as the name suggests, exploits speculative execution. This hardware technique detects when a program decision may be blocked on data from slow memory (RAM or lower levels of cache). Rather than wait, the hardware creates multiple speculative machine states based on the possible outcomes of the decision. It appears possible from the discussion that there can be several such “forks”, which can continue until some earlier decision is available, or no further “forks” can be created. Eventually, one of the speculative states becomes THE machine state and normal (non-speculative) computation resumes; the other states never become architecturally visible and simply “disappear”.

In CPU’s with small register sets (x86, MIPS, ARM, etc.) and deep internal pipelines (x86), it’s much more likely that a variable will not be “live” in a register, so this technique can pay off handsomely in those cases.

The flaw exploited by Spectre (whose meme really should be Blofeld’s cat) is that some side effects of the speculative execution don’t actually disappear, specifically, speculative values loaded into cache. This allows the attacker, using ROP or other techniques, to induce the victim into loading information into the cache without actually using it, to be harvested later.

According to the authors, Spectre attacks are effective against x86 (what isn’t, really?) as well as the RISC-based ARM and MIPS architecture.


Meltdown, so called because it “melts down” the normal address space protections, exploits a different type of execution speed-up: out-of-order execution. This technique dates back to the 1960’s, when Rob Tomasulo developed an algorithm to dynamically re-schedule instruction execution to allow otherwise-blocked instructions to proceed if they didn’t depend on the stalled instruction. An extended approach, out-of-order superscalar, goes even further and allows multiple, independent instruction streams to be executed in parallel when resources allow.

Of course, when machine exceptions occur (page faults, system calls, etc.), the architectural state of the machine must be made consistent with the logical state at the time of the exception, meaning that multiple instructions following the exception are “discarded”. Like Spectre, Meltdown harvests information from visible state, e.g., caches, that are not properly cleaned up.

An additional component of the attack is a memory region, virtual or physical, that maps all (Linux) or most (Windows) of physical memory at a different set of addresses than the user space. Interestingly, the authors were unable to affect some attacks on ARM and MIPS architectures, but similar, simpler attacks, also work.


The Year 1974 was notable for many important events. The first recorded surviving sextuplets were born in Cape Town. People Magazine was first published (Mia Farrow on the cover), while the Brady Bunch and Lucille Ball both made their final appearances on TV. ABBA wins the Eurovision song contest with “Waterloo”, and Queen releases their second album (Queen II). What most people remember, thought, is the on-going Watergate investigations, culminating with the August 8th resignation of Richard Nixon.

What most people SHOULD remember, though, is that 1974 is the birth year of the x86 computer line. An amazing variety of bells and whistles have been added over the years, but the basics of the architecture remain unchanged. The 8080 was implemented in approximately 6000 transistors, compared to the Nehalem at 731M. Over 120,000 times as many transistors, but the programmer (remember – everything runs in assembly!) is still stuck with small register sets, two-operand opcodes, and variable-length multi-cycle instructions (although see below …)

So, what did Intel do with all those transistors? On-board caches are there (up to 24MB shared LLC), but the bulk of the real estate goes into two functions: compatibility (Intel’s bread and butter) and performance. Performance comes from two sources: specialized instructions (e.g., MMX, AES, etc.) and – you guessed it – speculative, out-of-order, deeply pipelined instruction execution.

When 30%-40% of your chip area is already burned on supporting and speeding up legacy code and dusty decks, the Intel engineers may be given some forgiveness for not taking the time and additional chip area to properly clean up the instruction execution.

This raises the question: can we really meet the needs of 21st century computer security with a 44-year old architecture? The answer has been repeatedly found to be “no” – Spectre and Meltdown are just the latest in a long line of goofs, oopses, and oversights.

Enhancing computer security is like changing a building design to be taller. You don’t make a building taller by simply adding another floor. You have to think of lifting the existing building and
inserting a new foundation (including mechanicals, environmentals, etc.) to support it. Computer security isn’t frosting you put on the top (or, as Bruce Schneier says “magic fairy dust”) – it must be built in from the ground up – and ground, in this case, is the CPU.

EPIC and Itanium

Bill Worley, the chief architect of Itanuim and co-founder of Secure64, was obsessed with computer security. He intrinsically knew this foundational principle, and understood complexity is the enemy
of security
. As an early contributor to IBM’s RISC projects, and as the chief architect of HP’s PA RISC family, he also knew a few things about what does and doesn’t pay off in the chip area. He looked at the vast chip areas devoted to out-of-order and speculative execution and knew this was a possible area for attacks. He also knew this could be much better applied to additional caches and execution units, leaving the task of figuring out parallelism to compilers and software tools, explicitly specifying this to the hardware. Thus was born the EPIC architecture: explicitly parallel instruction computing.

But parallelism wasn’t enough – the architecture had to allow for better security than before. After all, this was to be the new foundation. So, numerous features, some new, some old, were melded into a unique, flexible, powerful memory architecture. Additionally, the internal pipelines had to properly clean up after themselves.

After Bill retired from HP in 2002, it was natural for him to think of this architecture, now released as Itanium from Intel, when approached on how to build a secure webserver. The rest is the story of Secure64.

Itanium vs. Spectre and Meltdown

The Itanium platform is naturally immune to both Spectre and Meltdown precisely because the complex, expensive methods used to speed up a 44-year old architecture are completely absent in Itanium.

Itanium execution is explicitly parallel. It is the job of the compiler or coder to lay out the instructions and tell the hardware what can be done in parallel. Linus once quipped that he’d like to see an out-of-order Itanium (probably something he regrets saying, now), showing himself clueless about what EPIC and Itanium were about.

Without out-of-order execution, there is no way for the Meltdown attack to work.

Likewise, there is no speculative execution in Itanium. Instead, the architecture provides powerful branch prediction and predication, a concept generalized from ARM (sadly, abandoned in AArch64) to avoid branching altogether.

Moreover, the vast IA-64 register set dramatically reduces the chances that a data item would be loaded from memory at the time it’s needed. Let’s consider the first Spectre example:

if (x < array1_size) {
y = array[array1[x] * 256];

In Itanium, if array1_size is known to be unchanged in the function, it would be loaded early and maintained in a register, as would the addresses of array1 and array2, so the Itanium coding for the expression would be:

cmp.ltu   p6, p7 = r13, r14
shladd    r8 = r13, 2, r15 ;;

(p6) ld4 r8 = [ r8 ] ;;

(p6) shl r8 = r8, 8 ;;

(p6) add r8 = r8, 8 ;;

(p6) ld4 r8 = [ r8 ]

Notice there’s no branching; further, the architecture definition ensures that no results of predicated operations are architecturally visible, even in the case of loads, stores, or exceptions.

There is a Itanium feature called speculative loads, but it is an entirely different mechanism, explicitly controlled by software. It is rarely generated by compilers and almost never appears in hand assembly. This means the attacker would have to rewrite the victim code, but then why bother with the subterfuge if you can do that?

SourceT® vs. Spectre and Meltdown

Like its underlying CPU, SourceT is naturally immune to both Spectre and Meltdown, but adds extra defense-in-depth.

The first and largest hurdle a Spectre or Meltdown attacker must overcome is injecting the attacking code into a running system. And this, quite simply, cannot be done:

(1) The boot image is cryptographically authenticated, so “trojan” images will not boot.

(2) Once loaded, all executable pages are locked-down and accessible as data, read or

write; there is no mechanism to add new code pages.

Even if an attacker can add code (he can’t), there is no way for it to do anything to the victim:

(1) Unlike x86, ARM, MIPS, etc., all program control information is stored in a separate

backing store. The address is unique per thread, not programmatically available outside

the thread –  not even within the thread, really, and stored in high-privilege
memory, as well.

(2) SourceT does not run with hyperthreads; there is no share  branch target table for the

attacker to manipulate.

(3) Each thread’s private memory is also protected with a 24-bit protection key. So, even if

the attacker knew the address(es) it wanted, it couldn’t read or write them.

Meltdown would have a “meltdown” because, even failing all other impossibilities, there is no space or spaces, privileged or otherwise, that map all of physical memory for reading and/or writing. And, as with any load/store architecture, indirect branch prediction/speculation is not an issue; Itanium goes further and requires indirect branches to use a special set of registers which can only be set from integer registers, never stored or loaded directly.

Please build securely – before robots kill us

Over the past couple of weeks, the world has been given WannaCry, which moved like wildfire through the globe and has given rise to multiple theories of origination from North Korea and not North Korea, and was dubbed “a pretty shoddy piece of work”.  As of this writing no one is certain of the origin.

We are told now that the weaponized EternalBlue at the core of WannaCry is in its successor  – EternalRocks, but there are an additional five tools for a total of seven NSA hacking tools.  We are also told that EternalRocks is here, operating in the shadow on machines and the dark web. Please do not forget we also have Adylkuzz to worry about, massive DDoS attacks by IoT botnets, data breaches and on, and on and on.

The point of this is that we live in an incredibly insecure world that causes real economic pain – and we need to figure out how to build with security before we have robots in our homes.

Can you imagine what a hacked human-scale robot in your house or your workplace could do? They could steal you blind, beat you up, kill you, kill your pets, burn your house down, push you out a window or down the stairs, spy on you, steal your car – the list goes on and on.

We have our current security problems due in large part because the originators of the internet, email and computers – pioneers of instant communication and creators of the global village – simply did not have security in their worldview.  The internet was not purpose-built to be secure.  Now we have learned that the Internet of Things (IoT) did not consider security either.  We need to stop thinking about security afterwards, and start purposely building security into the architecture of connected devices that can affect our lives.

We need to do this when we build-human scale robots that will be in our homes and in our lives.  Because our concern over what happens with AI will pale next to what could happen with the natural intelligence of hackers and cyber criminals (and ex spouses, angry neighbors, etc).

Please build securely

The Grinch Comes Early for BIND Users

[vc_row][vc_column width=”2/3″][vc_column_text]The grinch showed up early for BIND users this year, in the form of two new critical security vulnerabilities that can crash BIND. The two vulnerabilities are:

• CVE-2015-8000

• CVE-2015-8461

ISC has released patches of its BIND software that correct the problem.

Users of BIND-based appliances from vendors such as Infoblox, Bluecat Networks, BT, Efficient IP, Radware and F5 are advised to contact their vendor for more information about the availability of a patch.

Secure64 products, which are not based on BIND, do not have these vulnerabilities.

[/vc_column_text][/vc_column][vc_column width=”1/3″][vc_single_image image=”2518″ img_size=”500×600″][/vc_column][/vc_row]

Secure64 DNS Products Not Vulnerable to BIND Security Flaw

On July 28, 2015, the Internet Systems Consortium reported a critical security vulnerability in BIND, CVE-2015-5477. This vulnerability, which affects both BIND recursive and authoritative servers, is caused by an error in the handling of TKEY queries, allowing a remote attacker to crash BIND by sending a deliberately constructed query.

This vulnerability is considered critical, as it cannot be prevented through ACLs or configuration options, and affects all versions of BIND 9 (BIND 9.1.0 through 9.10.2). Successful attacks on unpatched BIND servers can result in a loss of DNS service, potentially making an organization’s web, email and other internet-connected servers unreachable.

BIND users are strongly encouraged to patch their servers immediately, as attacks against the DNS servers have already been reported. BIND-based appliances are also vulnerable and should be patched – customers are encouraged to contact their vendors for additional patching information.

Secure64 DNS Cache and DNS Authority products, which are not based on BIND, do not contain this flaw, and do not require a patch to provide protection against these attacks.

Secure64 SourceT OS not vulnerable to NTP flaws

CERT recently reported two Network Time Protocol (NTP) vulnerabilities (CERT VU#374268 April 7, 2015) . The first one concerns some versions of NTP Project software that will accept packets without authentication digests as if they actually had valid digests attached, and the second one describes a Denial of Service (DoS) scenario in which an attacker can prevent two peering systems from synchronizing. Neither NTP vulnerabilities affect Secure64 servers.

In the first case, no NTP Project code is used in the Secure64 NTP implementation.  In this implementation, associations that specify the use of authentication digests require all incoming and outgoing packets to have attached digests; any incoming packet without the required authentication information is treated exactly like a packet with an invalid digest, and is dropped.

In the second case, Secure64 NTP never peers with external servers, but rather forms a consensus among servers using periodic timestamp queries. This approach is not as precise as traditional NTP peering, but provides timestamp resolution well within the requirements of DNSSEC signing operations.  Since there is no peering being used, there is no way to disrupt a peering session, and hence no DoS vulnerability. This strategy conforms to the security best-practice of minimizing the code paths that are traversed, in order to maximize resistance to network exploits.

More Defenses Against Pseudo Random Subdomain Attacks (PRSD)

Last year we reported a new kind of DNS attack that we called the “Water Torture Attack”. This attack is also known as the Pseudo Random Subdomain Attack (PRSD, although we still like our name better).

In this attack, hackers send queries to open proxies around the world for random, non-existent subdomains of legitimate domains. For example:

These queries are forwarded to DNS resolvers at the upstream ISP. Although the attacks are intended to take down the authoritative servers for these legitimate domains, they have the side effect of dramatically increasing the load on ISP’s DNS resolvers to the point that they, too, can become overloaded and either slow down or crash.

Here are some additional steps that DNS operators can take, in addition to the steps we outlined in our previous blog, to protect their resolvers from these attacks:

1. “Prudently provision” their servers with enough RAM and query capacity. The attacks impact the resolver because it causes them to run out of critical system resources. By increasing these resources, the resolver may be able to sustain the higher recursive query loads.

2. Tune their configurations to maximize the number of simultaneous recursive queries allowed.

3. Automatically block IP addresses generating too many SERVFAIL responses, if possible. This capability is not available in many DNS resolvers, but is a new feature of our DNS Cache product.

Firezilla FTP

Recently, a fake version of the popular Filezilla File Transfer Protocol (FTP) client has been made available for download on some sites. This fake version of Filezilla looks and works as expected but it also harvests login credentials in the background. These credentials are secretly sent to a hacker owned site.  This is clearly a concern for any network and action must be taken to limit the damage. There are two things you should do:

1.       Block the stealing of credentials

The domain name that the hacker used to send credentials to is This domain name currently does not resolve, as the nameservers appear not to respond to DNS queries anymore (interestingly enough they still respond to ping). Additionally, the FTP server also appears to be down. So the worst crisis might be over. But to be safe you should blacklist in your DNS server. If you are using Secure64 you need to add a line like the one below and reload your cache server:

local-zone: “” refuse log

2.       Find and clean up your clients

If your DNS server is capable of logging blacklist hits, then now is the time to check your logs and see if any of your clients are using this fake Filezilla client.

By using the log option in the Secure64 example configuration above you can see which clients are trying to access the site. You can then reach out to them and make sure they remove the faulty FTP client.

More info can be found here: