About Mt. Gox flaw from a security expert

[muad_dib]

Okay much improved (B+), but here are some things to remember before you take your exam.

1) The statistic Psi-hat(linux) is a random variable that is an unbiased estimate of the constant parameter Psi(linux).

Not only it is unbiased, but it is asymptotically consistent.

Anyhow I would like to point you that a statistic IS NOT a random variable.

2) You are using random variables (sample statistics) to test a hypotheses about the constant parameters Psi(linux) and Psi (BSD)
    [Not testing a hypothesis about these random variables]

I'm not sure I understand you here, maybe it's just my english.

3) The parameter Psi(linux) is a constant, and is therefore not correlated with anything.

It's a function over a sample. Change the sample, and the statistic change. We take this statistic to measure the correlation between the proprieties of two samples.

4) If your TA is an ass, they will dock you points for not using the conventional labels H0 and H1

that's ture

Much More Important Lesson: Don't mix in random jargon about topics you don't fully understand to impress other people. Focus on your core competencies and people will take you more seriously.

Maybe you missed the fact of how many insults I got, and how many "engineers" were trying to educate me.

[1714790669]

1714790669

[1714790669]

1714790669

[muad_dib]

sorry for the bad estimate... it is still only 5% of the code that is relevant.

so 5% is most of the code?

Please define relevant.

[kokjo]

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.

The Linux kernel uptime rolls over at 497 days. The system doesn't go down, the uptime is just reset.

Linux, incidentally, has more eyes, so more seen bugs.

I like freebsd, but linux is much better for sysadmins.

+1

[TheGer]

Look can we all just run Windows and be happy already... 

[kokjo]

sorry for the bad estimate... it is still only 5% of the code that is relevant.

so 5% is most of the code?

Please define relevant.

stuff in:
the core code: http://lxr.linux.no/linux+v2.6.39/kernel/
the arch code for x86: http://lxr.linux.no/linux+v2.6.39/arch/x86/
some of the fs code(ext*, vfat, nfs): http://lxr.linux.no/linux+v2.6.39/fs/
the mm: http://lxr.linux.no/linux+v2.6.39/mm/
and the ipv* stacks: http://lxr.linux.no/linux+v2.6.39/net/ipv4/ , http://lxr.linux.no/linux+v2.6.39/net/ipv6/
and a few drivers from: http://lxr.linux.no/linux+v2.6.39/drivers/

i have also build my own little kernel, some time ago. it sucks, true. but it can start and print out a lot of information about the computer. (NO! it not just a custom build linux kernel, its a real os from the bottom).

[zer0]

This thread is pointless, since the 'auditor' handed over database access to somebody through total carelessness so breach would've happened regardless of OS. I bet the auditor had it lying around his gmail account or unencrypted on the desktop in a file called 'STEALTHIS.TXT'

[muad_dib]

This thread is pointless, since the 'auditor' handed over database access to somebody through total carelessness so breach would've happened regardless of OS. I bet the auditor had it lying around his gmail account or unencrypted on the desktop in a file called 'STEALTHIS.TXT'

they absolutely need to take steps so this CANT happen again.

[BTCrow]

@muad_dib

At first your post seemed wise, but

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

I stopped reading right here.

I don't know who you are, but you know nothing about security.

I loled a lot on this one and I completely agree. Even if I prefer nginx or apache to run software and get an extra level of security you can also secure an IIS very easily, and this without knowing a lot about computer security. Look how much flaw from new nginx and apache have been reported and look how much flaw on IIS have been reported (securityfocus) you'll see that what you say is completely out of bound...

Also php / perl / etc can be attacked if badly codded, daemon running on linux can easyly be attacked too, so this is complete no-sense.

[BTCrow]

http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation

Especially when you're picking data as selectively as you do.

I'm not going to start a flamewar. Please respect my objective opinion. I will respect your personal belief.

http://people.freebsd.org/~murray/bsd_flier.html

http://www.cvedetails.com/vendor/6/Freebsd.html

http://www.cvedetails.com/vendor/33/Linux.html

Not only freebsd has less vulnerabilities, but they are also less serious (check exploit or data execution)

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

[muad_dib]

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

But if you know what to do and need maximum reliability and security, without going Itanium, then BSD is a very good choice.

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

[jgraham]

http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation

Especially when you're picking data as selectively as you do.

I'm not going to start a flamewar. Please respect my objective opinion. I will respect your personal belief.

http://people.freebsd.org/~murray/bsd_flier.html

http://www.cvedetails.com/vendor/6/Freebsd.html

http://www.cvedetails.com/vendor/33/Linux.html

Not only freebsd has less vulnerabilities, but they are also less serious (check exploit or data execution)

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

I'd agree that OpenBSD has security as an imperative for it's dev team and while ASLR isn't the be-all of security.   I would contend that it does show a team taking a proactive approach to security rather than simply reactive patching.  As far as I can tell even FreeBSD 9 doesn't have it committed to the roadmap (it was suggested years ago though).

[jgraham]

Okay much improved (B+), but here are some things to remember before you take your exam.

Really?  Perhaps you can explain to me what you think he's trying to do here.

To me, even if "reliability" (as defined by Netcraft) was correlated with "security" (whatever we mean by that).   The kind of analysis you'd want to do here is a simple comparison of categoricals.  So ANOVA is the tool of choice.   Looking at the Netcraft data linked to early on it's pretty clear that things like failed requests, DNS latency, connect latency and first byte latency have little to do with uptime.  Sure you could make up a way they could be related to a security event (like say connect time or failed requests are related to DoS attacks but you wouldn't be able to differentiate between that and every other event).  What's left after that?  Outage - which might be related to a security event requiring a reboot but there almost everyone is at zero.  Except for two BSD sysetms and one linux system.

So I don't even have to boot up R to tell you that the correlation coefficient here is going to be next to nothing (and probably bad for BSD).

From where I stand this is an "shows promise" mark and where I grew up that's a C. ;-)

Jono

Edit: So drudging back through his morass of poor English.  It sounds like all this nonsense is actually about counting "serious" flaws per system over some time period? Exactly how does *that* become a security metric?  Not to mention that using the "flaws" metric is very likely not going to follow the kind of probability density function one is expecting.

I'd like to take a moment to say that math isn't magic.  The numbers you put in need to be meaningful and the operations you perform on them need to say something...*shakes head*
He might as well have taken the square root of spiders and integrated it by batman...

[kokjo]

Sorry for the double post, BSD system is A LOT less used than nux system that's why you,ll see less vulnerability. I'm a vulnerability researcher and I can ensure that when I have time to research for something I won't be loosing my time doing research for software not used a lot, I'll do research for IE / Firefox / Real Network etc... Of course the BSD are designed to be more secure but if you badly use it or you do not know how to use it, it will be less safer than running a nux or windows with good security mechanism on it.

But if you know what to do and need maximum reliability and security, without going Itanium, then BSD is a very good choice.

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

OMFG! you are now comparing a chip to a operation system.

[jgraham]

I would like to make you a question: why do you think that BSD had the 3 top spots in the reliability chart?

Do you think that the fourth company wasn't as good as the first three?

Because the latency for DNS, first byte and connect were lower.   Exactly where is the data that those strongly correlate to security events?  Nowhere.
For all you know this has nothing at all to do with the OS.  Cluster size, hardware config, network organization (such as the composition and placement of edge devices).  Heck we don't even know that all of these systems are under the same load.   All effect these kinds of statistics and considering that we are talking about averages without any idea as to their VARIANCE the placement might well be random.

Guess the mouse dropped out of stats?

[muad_dib]

OMFG! I like to embarrass myself in public.

I'm sorry for you.

[kokjo]

OMFG! I like to embarrass myself in public.

I'm sorry for you.

you really are a troll.

[muad_dib]

I'm sorry for you.

you really are a troll. Anyhow I'm too busy to see that because I'm still reading most of the linux kernel source. I just need 148 years more.

You just joined ignoreland alnog with the jgraham.


Even if I dont reply to you, please keep on posting, to keep the lulz up

[iBTC]

I'm sorry for you.

you really are a troll. Anyhow I'm too busy to see that because I'm still reading most of the linux kernel source. I just need 148 years more.

You just joined ignoreland alnog with the jgraham.


Even if I dont reply to you, please keep on posting, to keep the lulz up

#Lulzsec

[muad_dib]

You just joined ignoreland alnog with the jgraham.


Even if I dont reply to you, please keep on posting, to keep the lulz up

#Lulzsec

Lulz for life.

[makomk]

I'm sure you know that source code doesn't depends on archs, as archs are handled by compilers.

LOL *rolls on floor laughing*. That's a good one! You do realise that we're talking about kernels here, right? Compilers don't know about page tables, or context switching, or power management, or interrupts (on most platforms), or any of a number of important architecture-specific things that kernels need to manage. The code to handle this is in the architecture-dependant arch/ directories of the Linux kernel. (I believe the BSDs handle the seperation between architecture-independant and architecture-specific code differently. Never used them though.)

I ported android to the vending machines. And if you have a barely knowledge of how android is structured, you would know how complex is this task. Obviusly I was not alone.

Android is not Linux. Developing Android drivers and porting it to a new hardware platform is not that similar to developing Linux drivers and porting that to a new platform. Android's based on the Linux kernel, but it has enough fundamental changes to the driver APIs that they're not really compatible.