Unfortunately this topic has turned into a dick-measuring contest.
Yeah, the waters cold aint it? 
Topic: About Mt. Gox flaw from a security expert - page 8. (Read 34182 times)
Disclaimer: I am not a programmer. But I know how to find out about industry standards: "the marketing director of Compaq's OpenVMS Systems Group states that there are over 400,000 systems running OpenVMS, supporting over 10 million users. Sample VMS customer sites include: numerous stock exchanges, Bank Austria, Government Securities Clearing Corporation (GSCC), International Securities Exchange, Hydro Quebec, and Northern Light. Intel's fabrication plants rely on the use of VMS in the fabrication of their Pentium 4 and Merced class chips"
I have, however, attempted beating up a VAX. I won, barely, but this was 20 years ago. They have been improving it since then.
I have, however, attempted beating up a VAX. I won, barely, but this was 20 years ago. They have been improving it since then.
I'm not an expert (someone with some particular level of expertise), I'm a professional (someone who does this for a living). I haven't touched VMS since I was eighteen and was hired to develop for the Ministry of Education's 8530. I admit I found DCL's parameters and qualifiers rather intuitive and I think I've always had some admiration for Cutler.
My only opinion here is that systems like these are difficult to compare. For example VMS has a bunch of security certifications which is might be okay when comparing it against other proprietary systems with money behind them but few Linux distros would bother getting an E3 certification. Especially since the common criteria covers IIRC hardware and software. So it's not enough to certify Linux but if memory serves you would be certifying some collection of server + OS. Which makes it of more value to those vendors who have control of the hardware and the software.
Otherwise what do we compare on?
Do we count flaws? Hardly fair even if these counts existed since these systems are not nearly as widely used as Linux.
Features? Does it do ASLR? Who knows? How much entropy is in their implementation?
See what I mean?
It's not as clear as comparing a Non-Stop system to a Linux system.
Wow, this thread was fun to read...
Unfortunately this topic has turned into a dick-measuring contest.
Disclaimer: I am not a programmer. But I know how to find out about industry standards: "the marketing director of Compaq's OpenVMS Systems Group states that there are over 400,000 systems running OpenVMS, supporting over 10 million users. Sample VMS customer sites include: numerous stock exchanges, Bank Austria, Government Securities Clearing Corporation (GSCC), International Securities Exchange, Hydro Quebec, and Northern Light. Intel's fabrication plants rely on the use of VMS in the fabrication of their Pentium 4 and Merced class chips"
I have, however, attempted beating up a VAX. I won, barely, but this was 20 years ago. They have been improving it since then.
I have, however, attempted beating up a VAX. I won, barely, but this was 20 years ago. They have been improving it since then.
I actually had to skim after the third page...any of you "experts" running VMS? If you're going to pose and strut about security and all.
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".
Quote
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.
Quote
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.
Quote
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.
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.
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.
but look at openbsd. It had a backdoor for years exactly because less people audit the code.
Not true, prove it. 
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'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.
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.
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'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.
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
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
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.
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.
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.
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.
"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.
Quote from: muad_dib
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...
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.
Quote
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.Quote
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.Quote
Security is not a concept.
Actually that statement didn't say it was. All that sentence said is that security *contains* concepts. Quote
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.
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.
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.
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?
Quote
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.
Jump to: