About Mt. Gox flaw from a security expert

[Rob P.]

some people would also find it easier to run windows xp on your vending machine.

Good luck running xp on arm. Without a GUI.

Or trying to get PCI DSS compliance for XP.

PCi compliance for XP is easy.  SP3 is compliant if properly virus protected.
Before just touting stuff, at least provide your sources.

From:  http://www.transactpos.com/Integrations/VeriFone/PCICompliance/tabid/146/Default.aspx

What versions of Windows are PCI Compliant?
     Vista Business Edition (32-Bit)
     Vista Home Premium (32-Bit)
     Vista Home Basic Edition (32-Bit)
     Windows XP Professional Edition (32-Bit)
     Windows 2003 Server Edition (32-Bit)

[1713461511]

1713461511

[1713461511]

1713461511

[1713461511]

1713461511

[1713461511]

1713461511

[1713461511]

1713461511

[muad_dib]

Before just touting stuff, at least provide your sources.

Windows is not compliant itself. It is the combination of the software used and OS.

Compliance is very expensive, and it is much more expensive on windows than linux.


Sorry, but quickly googling this time didnt cut >)

[jgraham]

Your original point seemed to be that FreeBSD is more secure than Linux.  I'd say you haven't made your point.

He doesn't really need to.  

I contend that if you are making an argument then it's up to you to support it.   Clearly, he doesn't need to convince you.  That's well and good but it still leaves the point as conjecture.

In the CS community, it's well known that BSD is more stable, secure, and the best OS for critical infrastructure, while Linux is more friendly, flexible, and better for hobbyists or businesses that can save money (by hiring cheaper Linux fanboi rather than expensive real computer scientists).

I always find it interesting that people want to refer to the outcome of applying a complex and nuanced term like "security" to some product as being "well known".  Speaking as a member of the aforementioned "CS community" (a la Dijkstra :-) )

Referring to a commonly known fact, such as the security of BSD vs Linux, is not an argument.

If it were a fact, then you would be able to point to some clear and objective evidence of that right?  (Keep in mind that because you are referring to 'security' as some kind of blanket term you'd be responsible for providing that kind of evidence for the majority of aspects of the term and of course how exactly you know that your set of aspects is the majority).

Even if there happens to be a gainsaying fanboi present to dispute the widely recognized consensus reality.

Nice labeling there mac.  This isn't gainsaying.  I, simply as a IT security professional and the holder of a degree in computer science, have seen no set of well-defined, broadly scoped evidence that BSD is superior in "security" to Linux.  Nor in my conversation with other security professionals or members of the CS community (like my alumni, Usenix attendees)  see any clear consensus as to the superiority of BSD.  I have, certainly met people who make that claim but they always seem to fall down when trying to come up with a general definition of security or if they do they fall down in substantiating it with regard to their favored OS/Platform/Giant Spider.  Ergo it seems reasonable to me to call such a term "complex" furthermore given that even the most secure systems from a theoretical point of view can be entirely undone in implementation (such as EMF side-channel attacks on QKDS) it seems again reasonable to me to call such a system "nuanced".  Given these two facts (using the term correctly here).  I think it is entirely justified to be mistrustful of any and all who consider "security' as an open and shut case for product (or platform or giant spider) X over product (you get the idea) Y.

Please re-read my use of the phrase "well-known" in its proper context of me speaking about the real CS community.  And by "real" I mean EECS engineers and computer scientists, not cloud-happy corporate consultants and l33t Geek Squad linux fanboi.

What do you want from me here guy? The two sentences above tell me to look at your use of the term "well-known" as: your opinion of the opinions of two very large groups of which your sample size is probably so small and poorly randomized it's useless.  Not to mention that even if the majority of those two groups held the opinion you claim it still isn't necessarily meaningful   Computer Science and EECS people do not always have a background in computer security.   Making their opinion anywhere from questionable to useless.   Given the size of the groups and the variance in the population's skill set you could easily be getting the opinion of the least qualified people. I mean would you really rank the opinion of someone's who's focus was in Combinatorics or AI or Queuing Theory as equal or greater than Bruce Schneier or (going old school) D. J. Bernstien when it comes to an application or operating systems "security".  If you don't then how many Combinatoricists, AI researchers or Queuing Theorists make one Bruce or Dan?  

Not to mention it's not hard to find high-profile people in computer security who disagree on "well-known" concepts.

[Rob P.]

Before just touting stuff, at least provide your sources.

Windows is not compliant itself. It is the combination of the software used and OS.

Compliance is very expensive, and it is much more expensive on windows than linux.


Sorry, but quickly googling this time didnt cut >)

Still don't see your sources, maybe I missed them.  You've probably never actually gotten PCI compliance for an entire organization.
Oh, and Windows IS compliant itself, running nothing but anti-virus, desktop firewall enabled, having automatic screen lockouts, currently patched, and rotating passwords in a timely (< 90 day) fashion.  Just because the example I cited is one talking about an application, doesn't invalidate that Windows XP can be compliant, something you stated it could not be.

Or trying to get PCI DSS compliance for XP.

As stated above, piece of cake.

[muad_dib]

Still don't see your sources, maybe I missed them.  You've probably never actually gotten PCI compliance for an entire organization.

for an entire organization no.

For a bank yes.

Maybe bank are not safe enough for you.

Oh, and Windows IS compliant itself, running nothing but anti-virus, desktop firewall enabled, having automatic screen lockouts, currently patched, and rotating passwords in a timely (< 90 day) fashion.

you just forgot the credit card part.

[jgraham]

Before just touting stuff, at least provide your sources.

Windows is not compliant itself. It is the combination of the software used and OS.

Compliance is very expensive, and it is much more expensive on windows than linux.


Sorry, but quickly googling this time didnt cut >)

I think you've betrayed your skillset (again).  Level 1 vendor compliance is expensive.   It's not just expensive in CAPEX it's also expensive in OPEX.   Many vending machines would only need level 4 compliance.

[muad_dib]

If it were a fact, then you would be able to point to some clear and objective evidence of that right?  (Keep in mind that because you are referring to 'security' as some kind of blanket term you'd be responsible for providing that kind of evidence for the majority of aspects of the term and of course how exactly you know that your set of aspects is the majority).

So number of security flaws doesn't matter, because the more bugs you have, the better it is.

Uptime doesn't matter, because you dont need to reboot after a privilege escalation.

Design choices doesn't matter, because .... (insert stupid reason here)

Which evidence do you want? The holy spirit telling you that BSD runs your infrastructure?

Not to mention it's not hard to find high-profile people in computer security who disagree on "well-known" concepts.

Security is not a concept.

It's a question of counting flaws and measuring uptime.

[muad_dib]

I think you've betrayed your skillset (again).

I'm tired of all the arrogance you can find in this forum. I'm not paid to educate you.

If you want my opinion, please try not to be offensive.

[minerX]

I think you've betrayed your skillset (again).

I'm tired of all the arrogance you can find in this forum. I'm not paid to educate you.

If you want my opinion, please try not to be offensive.

You sound like a deuchebag.  Your original post and subsequent posts made me look at your posting history, and yup, you don't know shit.   

[jgraham]

So number of security flaws doesn't matter, because the more bugs you have, the better it is.

edit: I'm going to re-write this bit:
The problems with counting flaws are myriad.  As there is no mention as to *what* you're counting.  A DoS vulnerability may not be worth patching for a machine in your MZ running a service that's only used for a few hours every day.  Especially if it means dispatching a tech to a CO in Nowhereville USA.   This is part of your security profiling procedure where the company decides what are the things it's trying to protect.  Is it uptime?  Is it data integrity? Is it different for different servers?  On top of that "counting" is lame because it assumes that every flaw is of equal weight.  However in the *real* security world we don't think that way.   The term-du-jour is "modeling" but all this is is taking a page out of risk management's book.  Here we use MS's model DREAD - http://msdn.microsoft.com/en-us/library/ff648644.aspx . Essentially we assign every flaw a bunch of criteria like how frequently this could be taken advantage of or the skillset required to pull it off.   On top of that there is always remediation.  That is, is there a workaround or fix?  Can we use a firewall or our BGP equipment to mitigate the risk?

...and that's just for the group of outstanding flaws.  IIRC the little mouse was actually referring to bugs that either were closed or being addressed.  That metric is probably pretty close to useless.  It's almost an example of the gamblers fallacy.

Uptime doesn't matter, because you dont need to reboot after a privilege escalation.

Depends on where in the stack the escalation takes place and again if there are ways to mitigate it.  Uptime is a statistic that might tell you something about security but it can just as easily tell you something about funding, business goals, overall admin philosophy.   So it's not likely to be a very *good* indicator of security.

Design choices doesn't matter, because .... (insert stupid reason here)

Again it depends, for example a microkernel architecture could be considered a security design choice but the BSD's manage fine without it.

Security is not a concept.

Actually that statement didn't say it was.   All that sentence said is that security *contains* concepts.

It's a question of counting flaws and measuring uptime.

Like for example the idea that some mice might have that "security" is based purely on two metrics - is a concept.
Do you really need me to explain how those two metrics: Number of flaws and Uptime don't necessarily tell you anything about security?
Not to mention some of the postings you've made of these kinds of metrics makes me think you've never taken a statistics class.

[jgraham]

I think you've betrayed your skillset (again).

I'm tired of all the arrogance you can find in this forum. I'm not paid to educate you.
If you want my opinion, please try not to be offensive.

By far the most demonstrably arrogant person is you.  Just listen to yourself.

"I'm not paid to educate you".  No indication of humility there (the very idea that the little mouse would get some education is out of the question!)
"It's a question of counting flaws and measuring uptime." - no humility there either (can't possibly be anything else)
"I think your confusion might not arise from BSD." - oooh snap but not humble.
"Read better, hate less." - Yes, can't possibly be your writing.  Everyone else just reads you wrong.  That's really humble...no wait...the other thing...arrogant.   That's it.

To be safe, Mt. gox need a complete rewrite of their code, plus the use of a stronger infrastructure. But they wont do this, because it would cost them Millions to keep the server offline for 1 month.

That's actually kind of interesting from a security perspective.  In my experience:

i) Re-writes are rarely the answer and if you must do them targeted re-writes are better than whole app.  New code tends to mean new bugs.  It's often a case of the devil you know vs. the devil you don't.  
ii) It seems to imply that you couldn't just do a parallel development.  MG definitely has money and they are hiring.  No reason why you couldn't put the current code on maintenance and move your best talent to make the new branch.

These two assumptions make me wonder if you've every really been involved in large-scale development work.

Anyway looks like the mouse has taken his ball and gone home...

[marcus_of_augustus]

As an expert you should be aware that security and reliability is not the same thing. Also, if you look at the full table, the bottom two providers with a lot higher outage than everybody else run FreeBSD. If you calculate an average, FreeBSD will be much worse than the other solutions. Basically you can pretty much get any result you want from this list.

Reliability in strongly connected to Security. If you need to patch, reboot, or manage an intrusion then your reliability goes down. It also means that there is less security maintenance (even though freebsd update process is more obscure).

The table show us that if you want to be the most reliable, you need to choose unix.


Or you can count privilege escalation: 61 bugs in the last 7 years for linux, 3 for freebsd.

Or you can count vulnerabilities, even thought being freebsd smaller, this is a biased comparison.

Or you can do very rough estimation:

Google "Hacked by"+ linux: 2.3 millions results

Google "Hacked by"+ Freebsd: 230.000 results (one fold less!!!)


Anyhow let's put this way: My opinion is that FreeBSD is the most secure,  reliable and scalable OS. You think that Linux is more secure than FreeBSD.

Got a makefile for your *BSD bitcoind build you'd like to share?

Would help the community with more/different OS builds out there.

[jgraham]

Ok I admit that I'm going to cherry pick some specific features here but just reading over some of the security features in FreeBSD

RBAC: FreeBSD has a more sophisticated MAC but at least as far as the documentation I've seen there's no real "out of the box" solution there.  Available in Linux via GrSecurity since 2001.
FLASK: Yes, but they used the SELinux code to do it. (So obviously Linux had it first)
ASLR: OpenBSD yes (First OS to have it on by default).  FreeBSD, seemingly not-yet.  Linux has had this since 2000 via GrSecurity.

Kinda interesting for a "more secure than Linux" (by some as yet undefined standard) OS as endorsed by CS and CSEE professionals.

Anyway the point here isn't to bash BSD.  As I mentioned earlier I ran my systems on OpenBSD until about 2004.  For years I would have considered OpenBSD the best choice due to the attitude of those who worked on the project.   But it's not 1999 anymore and featurewise UINX-Like OS's are all getting close to parity.  What you need, IMHO is an experienced security professional to set down policies, procedures, practices and baselines based on your business assets and if you can't afford a third-party audit agency then they should try to fill that role.  They should be versed not just in CISSP style creation of policies but also have relatively low-level understanding of security on your platform of choice.

[ikonic]

Interesting Read. Seems to be a lot of angst of OS.

The bottom line is though, OS are only as strong or weak as the people hardening them.

Anyways, don't want to highjack the thread but for those would like to help contribute towards a Bitcoin Stock Exchange Security Standar,  I have created a thread here http://forum.bitcoin.org/index.php?topic=20377.0

[CubedRoot]

Dear Bitcoiners,

I'm sorry to hear that some people have had their account stolen, but I was expecting it.

The problem of Mt. Gox is that it grown too fast, without the correct investment in customer safety. The design of the site is not thought for security, and it is evident even from the API. Basic cornerstones like input validation, or safe data exchange are omitted, as if that was a blog and not a sensitive web application. Luckily Mt. Gox makes enough money to pay admins to control the money-flow.


The bigger problem anyhow, is that other exchanges have blatantly copied the design of mt. Gox, along with its flaws, and with a smaller budget. Thus I expect more security breaches. And this is a big problem for the credibility of bitcoins. Thus I invite exchange owners to:


1) Use the right software. IIS is a big no-no Also Linux should frowned upon. Unix is the way to go.

2) Update the software. You cant leave a known root escalation bug for 6 days!!!!

3) Have your code reviewed by a third party.

4) PHP security isnt too difficult, http://phpsec.org/projects/guide/ , still you missed most of the BASIC guidelines.

5) For god sake, you're moving hundred of thousand of dollars. Use a fucking dedicated server for the database. Accessible only by a local IP. If you wonder why I know this, then you should fire your admin.

If you own an exchange and would like to be safer, for a small fee (in the 5 figures) PM me, and I will tell you if your site is flawed, and if it is I can show you how I can have root access on the webserver at least.

I realized this guy was a dumbass when I read number 1.  I am a Redhat Certified Engineer, and I have several close friends and co-workers that are Linux Administrators for DoD, ORNL, and Y-12 (All in Tennessee).  Here is a reason why every single freaking one of these institutions rely on LINUX (mostly RHEL) for the utmost security. The OP has obviously no idea what SELinux is or just how actually secure it is.  Its a shame there are so many self declared "security experts" involved with Bitcoin.  I am no expert, but I do know my ass from a hole in the ground. 

[jgraham]

I realized this guy was a dumbass when I read number 1.  I am a Redhat Certified Engineer, and I have several close friends and co-workers that are Linux Administrators for DoD, ORNL, and Y-12 (All in Tennessee).  Here is a reason why every single freaking one of these institutions rely on LINUX (mostly RHEL) for the utmost security. The OP has obviously no idea what SELinux is or just how actually secure it is.  Its a shame there are so many self declared "security experts" involved with Bitcoin.  I am no expert, but I do know my ass from a hole in the ground. 

Warning. Total derail attempt. Warning.

Do the RCE exams still have a in-class practical portion?  I just finished the LPIC-1 - could have done it in my sleep.
Also do you or your peers have a lot of interactions with auditors on the system security side?  I keep finding places where inappropriate security policies (like 90 day password cycling) are being enforced not by admins but by auditors because said policy made it into someones best practices book.

[marcus_of_augustus]

Dear Bitcoiners,

I'm sorry to hear that some people have had their account stolen, but I was expecting it.

The problem of Mt. Gox is that it grown too fast, without the correct investment in customer safety. The design of the site is not thought for security, and it is evident even from the API. Basic cornerstones like input validation, or safe data exchange are omitted, as if that was a blog and not a sensitive web application. Luckily Mt. Gox makes enough money to pay admins to control the money-flow.


The bigger problem anyhow, is that other exchanges have blatantly copied the design of mt. Gox, along with its flaws, and with a smaller budget. Thus I expect more security breaches. And this is a big problem for the credibility of bitcoins. Thus I invite exchange owners to:


1) Use the right software. IIS is a big no-no Also Linux should frowned upon. Unix is the way to go.

2) Update the software. You cant leave a known root escalation bug for 6 days!!!!

3) Have your code reviewed by a third party.

4) PHP security isnt too difficult, http://phpsec.org/projects/guide/ , still you missed most of the BASIC guidelines.

5) For god sake, you're moving hundred of thousand of dollars. Use a fucking dedicated server for the database. Accessible only by a local IP. If you wonder why I know this, then you should fire your admin.

If you own an exchange and would like to be safer, for a small fee (in the 5 figures) PM me, and I will tell you if your site is flawed, and if it is I can show you how I can have root access on the webserver at least.

I realized this guy was a dumbass when I read number 1.  I am a Redhat Certified Engineer, and I have several close friends and co-workers that are Linux Administrators for DoD, ORNL, and Y-12 (All in Tennessee).  Here is a reason why every single freaking one of these institutions rely on LINUX (mostly RHEL) for the utmost security. The OP has obviously no idea what SELinux is or just how actually secure it is.  Its a shame there are so many self declared "security experts" involved with Bitcoin.  I am no expert, but I do know my ass from a hole in the ground. 

I'm inclined to agree ....  yet the number of people building bitcoind on a RH system or derivative numbers in the tens, if that ... absolutely no support that I can find for RH bitcoind ... except this howto for CentOS http://www.austinheap.com/assets/coins/531b6341e653b7b57a8f7f5cc3da79d9.pdf ....

C'mon you RH guys get in here and show them how its done, we need you. hware/OS/sware are the three-legs of security ... people have fogotten about 1 and 2 in the rush to make money I fear.

[iBTC]

but look at openbsd.  It had a backdoor for years exactly because less people audit the code.

Not true, prove it.

[CubedRoot]

The RHCE exams are pretty hardcore.  There are no multiple choice BS like most certification exams, hence why they are more valued across the industry as a defacto standard.  The RHCE exam is 100% lab based, and your work is judged by an examiner upon completion.  You simply dont plop down and choose from A through E on an exam. You have 4 hours to complete the exam, and usually everyone works up to the clock to complete.  There is also a a very small success rate on the exam, it hovers around 44% of folks that take it, pass it on their first attempt.

I was hoping to go to the Southeast Linux Fest in Spartanburg that happened a week or so ago and take the LPIC 1 and LPIC 2 tests, but life got in the way and I had to cancel my trip plans

At my company, we have a 90 day password expiration, and we enforce minimum 12 char alpha-numeric requirements for all production machines.  One of my colleagues is an RHCSS (Redhat Certified Security Specialist) and he works with SELinux contexts daily.  It is simply amazing what can be achieved with SELinux.  

[jgraham]

The RHCE exams are pretty hardcore.  There are no multiple choice BS like most certification exams, hence why they are more valued across the industry as a defacto standard.  The RHCE exam is 100% lab based, and your work is judged by an examiner upon completion.  You simply dont plop down and choose from A through E on an exam. You have 4 hours to complete the exam, and usually everyone works up to the clock to complete.  There is also a a very small success rate on the exam, it hovers around 44% of folks that take it, pass it on their first attempt.

See I like that approach rather than regurgitating the command options for three different package managers ;-) (and the one I actually use of course).  Nothing shows competence better than proving you can do the work.  My team has even given up on written tests in job interviews.  We've switched to doing "virtual labs".

I was hoping to go to the Southeast Linux Fest in Spartanburg that happened a week or so ago and take the LPIC 1 and LPIC 2 tests, but life got in the way and I had to cancel my trip plans

You will breeze through the 1.   I haven't read over the 2 yet.   The main reason I took them is that I'm taking a wack at teaching them in the fall.

At my company, we have a 90 day password expiration, and we enforce minimum 12 char alpha-numeric requirements for all production machines.

Yes, I wasn't trying to imply that 90 day cycles are generally inappropriate.   For example Windows domain admin accounts have so much power by default and are so widely used in the industry that we enforce heavy password rules.   However for regular users 90 day cycles with three iteration memories tends to have them writing the password down.  So we enforce complexity but not cycling.

One of my colleagues is an RHCSS (Redhat Certified Security Specialist) and he works with SELinux contexts daily.  It is simply amazing what can be achieved with SELinux.  

SELinux is incredibly flexible in my opinion but I think you hit the nail on the head there.  It's real power is in the hands of experts.   Which is why I tend to recommend GrSecurity - gradm can be run in a "learning" mode to create your RBACs for you.  I guess on the flipside PaX is more robust than execshield but not nearly as transparent in operation.  Other than those points I find it a matter of taste.