HYDRA Server

I was very surprised to see that my post in the bookmarks thread was the only to show under a search for "Bodacion."

http://www.bodacion.com/

This web appliance is likely the most secure single level server on the market. It is immune from all remote server level attacks including cracker, viruses, and worms.

The system runs Java web applications, utilizes domain based access controls or "compartments", effectively has a read only operating system with no command interface.

Its encryption technology is interesting, but my knowledge on such things is limited to the bare minimum to not bomb that CBK on the CISSP.

The site makes a lot of bold claims, but the majority of them are completely true, a few of the claims have a smidge of spin. For example the server cannot effectively protect objects from subjects in the same compartment even if the subject does not have explicit rights over the object. (multi-user web hosting for a simple example)

The true benefits of this system is the fact that it has essentially no administration requirements. Essentially no security configuration, no patching, no unusual access controls, no complicated rules files... I would guess that anyone who was familiar enough with computers to use MS Office could effectively run a secure and stable HYDRA server.

Anyhow I figured this would be of interest to some of you perhaps.

catch

This looks a lot like a planted ad to me. No patching? So I assume the code is all perfect, then? A fully-integrated solution! Yay, that looks like its defenses have a lot of depth. Granted, I'm not saying it's horrible, but I have difficulty believing that it lives up to its claims.

Oh, and it's "FIPS-approved" crypto is either 3DES or AES. Nothing exotic (that's a good thing, BTW). But, you know, they're totally abusing the term "biomorphic."

Most of the crap in the "reliability" section is just them using different words so as to appear more reliable. They say no OS failures, as they don't have an OS. I say *every* failure is an OS failure, as their entire codebase is the OS.

Yeah, a planted ad... that would make sense for me to complain about it being single leveled.

Quote:

---

No patching? So I assume the code is all perfect, then?

---

This is just daft.

1. Perfect systems do exist.
2. the system doesn't need to be perfect to have no patching required. It merely needs to be designed so that bugs cannot effect security related functionality. (it would not be the first system like this, not by a long shot.)

This system doesn't need depth of security, all it needs to do is isolate the web service from the rest of the system, which it does. The system lacks depth in functionality so depth in security would be anti-thematic at best.

The system has an OS obviously (nano-kernel their marketing deptmant has apparently dubbed it), it doesn't have a command interface and the OS may not be reached from the web service compartment. The reliability is very good as you'd expect with a system this simple.

"so reliable it has earned FAA and Department of Defense certifications to operate in flight control systems and other life-sustaining and critical environments."

It is by no means a perfect solution, but i wonder if we won't be seeing more of this type of least privilege extended to the entire box in the future.

The encryption system uses 3DES and their use of biomorphic is proper. the use it too seed data and in internal/transfer integrity checks. (but all of this information is on the site.)

Your entire post is argumentative, any reason for that?

catch

Looks interesting, however....

If they are hosting their website on their own device(perhaps???) it doesn't like opera very much. Loads fine in EI 6, but opera takes for ever to load the page(some images don't load).

Netcraft doesnt seem to have a very good idea what they are running, so, maybe they are running their own appliance.

Edit:

I take it back, their site just doesnt seem to like me for some reason. Now it is having trouble from both IE, and opera. But when I browse to it while terminaled into an office in another location, it is fine.

Quote:

---

Your entire post is argumentative, any reason for that?

---

Because it was a rebuttal to your breathless adoration.

You claim that perfect systems do exist. I can accept that. You offer no evidence that their system is perfect. Isolation and least privilege are great. I like them. But they don't mean jack if there's a bug in their TCP code. Anyone can ramble on and on about Java this and least privilege that, but they're just blowing smoke if the low-level implementation is flawed. Take a look at Marc Schoenefeld's recent post to bugtraq. Ohh, a way to work around one of Java's compartmentalization systems. Perhaps Bodacion's system is not subject to this type of attack, but perhaps it is.

I am not saying that they do not have good technology. I am saying that their marketing is completely wrong-headed. If you really do not patch the system, and there is ever a serious bug, you have a very expensive dorrstop/wAr3z server/DDOS zombie. If patching is automatic, and someone compromises their patch server, then you have a very expensive dorrstop/wAr3z server/DDOS zombie. If you have to manually patch, then they're lying.

Looking over their web site, they have implemented lots of other people's good ideas. That is a good thing. However, good ideas are not a magic bullet. They present their system as being a magic bullet. I do not believe them.

What they are offering is a system that is largely different from > 99.9% of the web servers out there, and is clearly not designed by idiots. This assures you a lot of obscurity and a non-stupid implementation. This protects you effectively from all the script kiddies out there. This is nothing to sneeze at. That is a long way from a perfect system, though.

Quote:

---

Perfect systems do exist.

---

Gödel is rolling in his grave over that one.


-Maestr0

Quote:

---

Gödel is rolling in his grave over that one.

---

:-) Yeah, I think s/he meant that perfect subsystems do exist.

Quote:

---

Because it was a rebuttal to your breathless adoration.

---

Maybe this is a language issue, because you could not have possibly been reading my post. The only place I say anything nice about it's security is that it is _likely_ the most secure system of a very insecure set of systems. (single level)
Then I went on to focus on a one of the system's theoretical issues. The only real plus I focused on was the lack of administration needed as you have effectively taken what would be a subsystem on a general purpose operating system and made it stand alone.

Quote:

---

But they don't mean jack if there's a bug in their TCP code. Anyone can ramble on and on about Java this and least privilege that, but they're just blowing smoke if the low-level implementation is flawed.

---

You clearly have no understanding of how this system works. You keep needing to place it in the context of a normal operating system. Even if the TCP implementation is flawed... what are you gonna do with it? You've got no access to syscalls that can violate system confidentiality or integrity, so what have you got? A fat goose egg.
Perhaps you should go back and read the documentation more carefully (or perhaps at all) and you will see that the only effective way to compromise data on the system would be via user supplied web applications, but even those cannot effect the system, only other objects within the same compartment. And even then it gets kinda iffy as to what exact access would be allocated to such a rouge process.

Quote:

---

That is a long way from a perfect system, though.

---

I never said it was a perfect system, I said it offered high security for a low security type system and that it was easy to administer. In fact, not only did I not say it was perfect:

Quote:

---

It is by no means a perfect solution

---

Learn to read before you try and show everyone how clever you are.

Quote:

---

Yeah, I think s/he meant that perfect subsystems do exist.

---

No, I meant perfect systems. They are merely the result of extensive formal methods and of course tremendous costs. Is this system in question perfect? Read above. It falls under #2 in that it is possible to design the system in a manner that it needn't be perfect to be immune security wise.
The benefits of high level trusted systems (to which this has taken a few aspects to extreme) is that you don't need to worry about patching because the model and security kernel are verified and user level software like the web server or like the IP stack CANNOT effect the overall system security. This concept has been around since the mid 70's, I am amazed you are not familiar.

They have done this in a rather standard way, that is to minimize the system so much that there is essentially nothing for an attacker to leverage. Nothing new, nothing creative... just the first time I'd seen it offered at the commercial level. Cobalt systems for example still have a general purpose OS on them.

catch

That is a very smart move. In fact that is the best security I have ever heard of. Instead of pumping out this huge arse firewall/killem all app, just give them nothing to work with. Funny. *Skript kiddie sit dumb founded*

We actually have discussed this before here. When the system was introduced they were offering to give the person who could predict the next "bodacion" in a series and brand new ferari. Or was it a million dollars? One of the two.

They gave you a file that contained 99 sequential "bodacions", and you were to predict the next one.

Many of us here worked on it, some seriously, some not (like me). It seems to me though that eventually their pattern will be found. Its only a matter of time.

I found no additoonal references to "bodacion" on this site, perhaps you are thinking of something else?

The encryption/seeding isn't really the point I was trying to make with this. Normally in the cases of trusted systems you have a collection of compartments with very limited functionality on top of a gernal purpose operating system. This system is perhaps a lazier, but very logical resurection of systems existing prior to modern trusted systems. Rather than using compartments, you use a system that is only capable of one thing (in this case serving web pages). This should offer similar if not better security than a decent trusted system, with far lower skill sets and costs required.

catch

Look, I'm sorry to be such a downer, but Bodacion has pulled the wool over your eyes. Their server appliance may not have a general-purpose OS, but it *does* have a JVM. Think about that for a second.

Okay, I'll spell it out. A JVM has all the complexity and power of a full-fledged OS. Buffer overflow? Maybe not, but that depends on the implementation of their JVM. Heap corruption? Why not, other JVMs have problems of this sort. This machine surely has the ability to act as a port scanner, DDOS zombie, attack relay, etc. They've clearly built in protections against this sort of thing, but the point remains. This is not a single-purpose machine. This is a full-fledged Java system, and is thus fully powerful and complex. It certainly has the groundwork to be more secure than Linux/BSD/Windows/etc., but that does not mean that it *is* more secure than those things. The services that the OS provides on a conventional computer are provided by the JVM on the HYDRA server.

More generally, there's a conceptual problem with the single-use web server. You can make something super-secure if you just want to serve up static pages. But the moment you want to do something real, you start to have bigger problems. So you want to write logs to an external NAS box? Well, that means you have to mount a network filesystem and write files to it. You want to have a database-backed dynamic web site? Well, you have to be able to run programs and connect to an outside database. At a certain point, you end up with a full, general-purpose, computing device. You have a large body of code, some of which undoubtedly has bugs in it.

The HYDRA has a JVM. It may not be a full JVS with SWING, ATK, etc, but there's still a lot of code there. And they've probably written their own networking and device driver code. They've possibly written their own partitioning system. That's a decent body of code to write for any group of folks, doubly so for a small company. The chances that all their code is perfect is pretty close to zero. In fact, I'd say that there's pretty good chance that somewhere in the system there's a bug that lets a remote, unauthenticated attacker run whatever code she wants. It probably won't take out the web server, but who cares? Only silly defacers want to hack the web server. The real danger is that an attacker can use the machine to launch attacks against other computers. This is a very plausible scenario.

Say you manage to modify a file in the IDS/Admin portion of the HYDRA. Maybe it's even in a reporting part of the user's web application. You make it so that connecting to the reporting interface downloads an IE exploit. Since the HYDRA is so good, you obviously don't need skilled security experts or defense in depth, and your IE is unpatched. Now, due to a minor vulnerability on the HYDRA, you've got BackOrifice installed on your LAN, and all your patient's medical records are getting funneled over to Jane Hacker's hard drive. Whoops. And all the while your HYDRA has been humming away, giving no indication that anything's wrong. Its nanokernel is unperturbed, its web-serving compartment is pristine. Who cares? You put all your eggs in one basket, and now you're 0wn0rz3d.

Security is not a technology. Security is an arrangement of interlocking systems, some of which are technologies. The HYDRA may be far more secure than a W2K/IIS web server, but it is neigh impossible that it is perfectly secure. Regardless of your web server, you should use other techniques to secure your resources.

j3r, on a normal system (Windows/Linux/UN*X) what you say is true. However despite this systems lack of hierarchical levels, in this instance it still has more in common with a trusted system than a normal system. (seems sort of an in-between step)

I have an analogy for you... the Kernelized Secure Operating System (KSOS). A bit of history for you, KSOS was a DOD project back in 1978 that was initially designed by Ford Aerospace and SRI International. The idea was a _provably_ secure operating system that could have UN*X run on top of it. All of the system's security functions are then enforced by the security kernel, so it doesn't matter how many zillions upon zillions of bugs and flaws exist in UN*X, none of them will ever grant any rights as the security kernel has been proven as secure. (finite state machine)

HYDRA works the same way, except on top of it's security kernel is the JVM rather than UN*X. This I suspect was done to avoid the stigma of trusted systems as being complicated and only appropriate for the military.

So break the JVM all you like, it will grant you nothing. In fact break every user land subsystem/application you like, the web server, the IP stack, the IDS, whatever... none of it will grant you any rights.

Security is a technology, people have just forgotten the lessons learned in the early days of formalized computer systems design.

catch

PS. Attached is the KSOS executive summary.

Ah, and now we stop sputtering into the wind and get to the crux of the argument.

Quote:

---

HYDRA works the same way, except on top of it's security kernel is the JVM rather than UN*X. This I suspect was done to avoid the stigma of trusted systems as being complicated and only appropriate for the military.

So break the JVM all you like, it will grant you nothing. In fact break every user land subsystem/application you like, the web server, the IP stack, the IDS, whatever... none of it will grant you any rights.

---

Perhaps no rights to the nanokernel, but I assert that it doesn't matter. Another analogy. The Linux kernel is pretty damn stable, and due to the whole protected memory thing, one app crashing doesn't take out another app (often, but bear with me here). So, great, your machine never crashes. Now say you're using Linux on the desktop, and you're running X11. Now, one of your X11 apps crashing can corrupt the X Client, taking out the entire X11 app. Since all the applications you care about are running under X11, one misbehaving app can take out everything you care about. Does it crash the kernel? No. But it doesn't matter. X11 is part of the critical infrastructure of your system.

Similarly, the JVM is part of the critical infrastructure of HYDRA. There's a web-based administration system, presumably running under the JVM. If you can get into the JVM, you can get into the admin system. You haven't gotten into the nanokernel, but it doesn't matter, because everything that matters on HYDRA appears to run under the JVM. They have merely swapped one big, unmanageable, insecure blob of code (the operating system) for another (the JVM).

I am fully able to believe that in Bodacion's system, you cannot gain control of the nanokernel from the JVM. I further believe that the JVM is powerful enough that no attacker would really care about the nanokernel, instead finding everything they need in the JVM.

Quote:

---

Security is a technology, people have just forgotten the lessons learned in the early days of formalized computer systems design.

---

I suggest that this is not the case, rather that it is a long way between a formal system design and working code, and a lot of mistakes get introduced along the way. After all, Java had a formal system design, but the implementation has proven to be full of errors.

i haven't used it and seems to be reliable , but i wouldn't change AS/400 for anything :D
i think this is off topic but i wouldn't change it :)

The act of crashing or not is irrelevant. the fact is, no additional rights will be granted.

JVM is NOT part of the critical infastructure of this system as far as security is concerned. It is not a part of the security kernel. Therefore everything else on the subject is moot. You can blow JVM up and try to make it dance anyway you like, it will not be unbound by the system security policy. (Just as why would anyone target the KSOS when you can target UNIX on top of it right? Or what about the JVM on top of the UNIX on top of KSOS? You are still bound by the original security policy which has confidentiality and integrity constraints.)

The integrity checks are in place (and part of the security kernel) to ensure that the JVM isn't altered and that only approved objects can be executed. So you can't leverage the JVM itself, and you can't feed it stuff.

The JVM will always be bound to the security policy that the security kernel hands down to it.

You seem to want to compare this to Linux, which is on the exact opposite end of the spectrum in design and security and implementation.

Quote:

---

I suggest that this is not the case, rather that it is a long way between a formal system design and working code, and a lot of mistakes get introduced along the way.

---

Formal design should and typically does include formal verification of the final product.

The whole point of this type of design is that it mitigates ALL application/user level bugs, errors, and flaws.

The system does have issues, but not the ones you seem to think.

catch

Quote:

---

JVM is NOT part of the critical infastructure of this system as far as security is concerned. It is not a part of the security kernel.

---

Sorry, I misread your previous post. (Thought you said "except it's security kernel is the JVM", rather than "except on top of it's security kernel is the JVM", a ridiculous proposition, I'm sure you'll admit.) The example I gave of an attacker attacking application code still stands. You still need defense in depth.

Quote:

---

Formal design should and typically does include formal verification of the final product.

The whole point of this type of design is that it mitigates ALL application/user level bugs, errors, and flaws.

---

Formal verification of machine code (or of your source code and compiler, or etc.) is rather difficult. I suggest you start with Sun's JVM. Have fun, kid. Make sure there are no errors in your reams of verification. Suggesting security through formal verification of a web server is only slightly more practical than suggesting security through unplugging the web server and melting it down into slag. The lesson "learned in the early days of formalized computer systems design" is that in almost every case, there is no business case for formal verification.

Haha... if I had said "except it's security kernel is the JVM" I'd be all over me. ;) Though when I relooked, at first glance I read it the same way you did... odd that.

The example you gave would only stand if the designers decided to be really dumb at that point and apply no security to the JVM. I still ask... how are you going to make the JVM do anything?

Java is not an appropriate language for formally verified code, you are better off with something like Modula-2 or perhaps even Ada.

All you need to verify is the security kernel. A feat that when it had never been done before cost the sum of ~10,000,000USD. (for a general purpose OS not a simple guard as this system is) Obviously with lessons learned, the comparative cost has come down significantly.

I am not sure how you can be faced with other more complicated system, that have exactly what you are talking about in terms of stuff beyond the security kernel, and not argue that all the private and US government labs are wrong and it isn't proven secure. But when faced with a system that would be far simpler to verify and has been verified for correctness that it isn't secure.

How do you reconcile this? Or am i misunderstanding you, and you believe that you are more knowledgable on security than those labs are? that is really the only way I can see that your arguments would be logical. (Do you have any exposure to trusted systems? The arguments you are making lead me to think no, and if that is the case I can provide some other reading if you are interested.)

catch

Like xmaddness said, they had that contest a while back. Well, I am not going to look at their site to see if they mention the results of the contest. And I don't remember the site where I saw it, but the system was broken. No one guessed the next number, but found a way to not need the next number. That happened durring the competition, and the entire thing was pulled for a while. I assume they patched the problem, but then that just proves that patches may be needed.

Quote:

---

Bodacion argues that the system's network transactions are completely safe because no two Hydra users will be assigned the same session ID, customer ID, or order ID. The company is so confident in Hydra's ability to ward off hackers that it sponsored an eight month-long contest: Bodacion vowed to pay $100,000 to anyone who, given the first 999 numbers in a sequence, could guess the next number (and demonstrate that the guessing mechanism could be successfully repeated). None of the 200,000 plus hackers who attempted the challenge was able to collect.

---

- http://careers3-stage.accenture.com/...6_Bodacion.htm

Quote:

---

More than 100,000 contestants from around the world have tried to crack the security mathematics that make Bodacion Technologies' HYDRA Internet server "hackproof" since the company issued a $100,000 challenge March 1. No one has won the contest nor succeeded in crashing the Web site where entrants register for the competition.

---

- http://www.intelligentx.com/newslett...h5_041002.html

Quote:

---

Bodacion offered $100,000 to anyone who could crack the algorithm. During the 60-day period the contest was held, hundreds of thousands of participants attempted to break the code, but no one was able to decipher any of the sequences generated by HYDRA’s algorithm.

---

- http://techrepublic.com.com/5100-6264-1047948.html

Quote:

---

Bodacion is sure enough that its Hydra Internet server is "hackproof" that it issued a hacker challenge that began on March 1. When the contest ended, no one could claim the $100,000 prize.

---

- http://www.umit.com/NewsReviews/Tech...technical3.htm

So... souleman, xmaddness I think you have confused the system.

catch

PS. Via a google search on Bodacion and contest i found no data in opposition to what I've pasted here. (though I realize some of these soruces are not exactly high assurance)

http://www.antionline.com/showthread...0&pagenumber=1


http://www.antionline.com/showthread...667#post473358



Simple search provides great results.

I entered "bodacion" into the basic search field and it returned just the this entry and the other I mentioned. Still does in fact.

Anyhow, none of these threads makes any mention of the contest having been won, which is the real point.

catch