All it takes is a crew that is loyal to that one person.
A few handfulls of minions and an evil genious. (Realistically though, I doubt the person would have to be much of a genious - basic knowledge of "mass" psycohology would go a long way).
And so what? We place trust in the hands of single persons and trust that they do their duties. In the end we're all dead anyway.
Now thinking about how a proper reference monitor could have been implemented in outlook to completely avoid this worm and all the others, and how these implementations are often just a few hundred lines of code - I vote for the "missing reference monitor" in Outlook to be the most expensive *missing* data out there;)
(See TCSEC for a description of the reference monitor concept, if you don't know about it)
Then whatever you do, make sure you build your systems on a B1 (or better) certified system, and that it's properly configured.
Take a look at Trusted Solaris. It is by no means a solution in itself, but it is a prerequisite for a moderately secure system.
The idea is, that even if your system is rooted, the intruder will not have access to change system parameters (root is not allmighty), he cannot run standard utilities if he entered via. the network (compartments, mandatory security and trusted paths), and his activities can be logged (auditing).
So you don't use a standard network stack. Instead, you create a communications library and use that in your applications.
How is that different from just using the network stack ?
Granted, it adds a tiny amount of obscurity. But your apps on the front-end will still be using your comms. library, and if I r00t your front-end, I will still be able to talk to the "secure" machine (using your neatly written comms library).
Fundamentally, you change nothing. You add a tiny layer of obscurity, but that's it.
So let me get this straight: You set up an "oracle" (a machine which you can ask to decrypt data and which will do so when asked). Your "security" lies in your "low-level" protocol (for which you obviously have communications code on the front-end machine).
Where's the security in that ?
Let's say I r00ted your front-end machine. Why don't I just look at your script or your binary and see that it sends the request over SCP. Or over a PERL socket reader.
You have added a very tiny amount of obscurity, but nothing that resembles security. Your "oracle" has no way of knowing who's asking, if you built the assumption into the system that "anyone who can ask must be in their good right to know".
Even if it's on a private network on another NIC, this doesn't help one bit. I r00ted your front end machine, remember - if the front end machine can talk to the oracle, so can I, when I'm root on the front end.
You may be able to add a little security resemblence with your "anomaly detection". However, it is quite likely that I am smart enough to just see how valid requests are built, before I try my own requests at the oracle.
So when you crack the server and get root, you need to go *all* the long way to a gdb which you attach to the running process, in order to get the key out.
Wow. Good thing it doesn't get swapped out, then the "print" from gdb might have taken an extra millisecond;)
It's easy; don't store the information. If it's not there, noone can steal it.
Store the address, name, phone number, visit history, mother's maiden name, shoe size, whatever you want - but don't store the credit card number.
I'm quite happy with entering my credit card information whenever I purchase something. Knowing that this information will not be leaked to the next script kiddie who drops by - you simply cannot trust security at sites with dropping revenues, budget cuts, etc.
Clearly, the number one priority for many business sites today is to keep things running. Security is only a problem if it's broken. And that only happens if you're unlucky... Yearh right...
Does anyone know if an encrypted filesystem is availble for OpenBSD ? Seems like it still isn't. Except for the hacks like CFS... Is there an encrypted filesystem which is ready for *real* use out there ?
I understand it allright, and I understand what I or anyone else could do messing with those databases. Now, I'm not the kind of person who would do such a thing - but I know what technology does to people who does not understand that it is not infallible.
The technology does not scare me one bit. What scares me, is knowing that *people* will be using the technology.
It's beyond me how anyone would trust their biometrics to random companies (or other entities). Hell, I wouldn't trust the government with mine (they can take prints from my dead cold hands).
The problem is, that they are not just creating a "hash" from your prints - they need to store the exact print in order for the recognition to work. This means, any script kiddie lucky enough to get into their database, will have the prints.
The next logical step is, to hook this system up to the feds and interpol (post sept-11 this is not fiction!)
The real problem will be, that people trust technology blindly. When I "check out" of the store, putting my thumb on the reader, and the alarm bells sound (and the big "armed and dangerous, shoot on sight" sign starts flashing), guards, police, whatever, will trust the damn machine.
Now if one could trust that the responsible parties would (and could) ensure "absolute security" around their biometrics systems, there really wouldn't be that much of a problem. But believing that IT departments in regular companies (or even government agencies) who all live with finite budgets will ensure that their back-end systems are un-crackable is naiive.
Luckily, the iris scanning in the airports is still optional (and actually sold at an extra charge, as some sophisticated "luxury" - hah!).
Am I the only one who thinks it's strange that while we get told about all these fantastic things that can be done which weren't possible a year ago, people still say convincingly that "you can't get the state from the system without leaving finger prints" ?
I'm sure we can't today. And I'm equally sure that someone is going to figure out a way to touch the system so insignificantly that the "reading" cannot be measured.
Like when reading from a hard-drive: Of course the head will alter the state of the platter when passing by - it's just so insignificant that it doesn't matter, and it would probably be hard to measure if anybody tried.
While this is fascinating and all, I just don't buy into the "can't cheat with this one". Many years ago, everyone agreed that you couldn't split an aton - which was natural, because "the atom" itself was a relatively new idea in itself at that time.
I find it hard to believe that the progress stops here.
Did anyone besides me notice, that the windows RDP server *ALWAYS* uses the same prime for the server<->client key negotiation ?
128-bit my arse, if any small government or large company can spend half a year pre-computing attacks for the single prime number that's used in all windows RDP servers.
The argument that someone else raised, that such a rule could exist because "people might be hanging around Sony's booth only to play games, and not go look at the other exhibitors", simply doesn't hold - for the following reasons.
CeBIT is the largest such exhibition in the world, there are more than 8000 exhibitors, and more than 150.000 visitors each day. You don't just "browse" the exhibition, you plan your visits from home.
The ticket is around $120 - you don't waste a day there just for playing a $40 game.
Sony let people play with their software, and so what ? They let me play with Linux on their PS/2 as well. And being an exhibitor there, I've let people play with our software in our booth as well. Just like Sun let me play with their software, IBM with theirs, etc. etc. etc.
Strange how people seem to believe that a superior force using bigger weapons is going to help against the inferior force that doesn't fight in a way where the size of weapons matter.
Face it - the U.S. is a superior military force today. Using bigger or smaller bombs is not going to make one bit of difference.
The way that other forces fight back, is naturally not by putting up their largest army, only to see it squashed by the bigger army. That would be silly. No, the way to conquor a larger state with your inferior army, is to strike them where they do not expect it. That is why someone used civil aircraft as bombs on Sept. 11th. Whether we like it or not, it's the rational choice (if you can talk about "rational" and "warfare" in the same sentence...).
Now before you condemn what I say here - think about it. If you were at war with a superior force, would you line up in rows and columns to be slaughtered by the superior force, or would you rather be smart and make a difference ?
One thing's certain; using bigger bombs is not going to make fewer people strike back. I fail to see the logic behind this escalation, should it pass.
And no, I do not applaud what's been happening in the world lately. If you think I do, read this post again. Re-iterate as you must.
No way ! I wrote my own widget set on Xlib back in 1996. Real men don't need bloat like Xt;)
Actually I did. Didn't use anything but Xlib. But it's gone now - you really need a capable and *standard* widget set (eventually comprising dialogs like "file open" etc.) to make apps that are nice (not use usable).
Today I use Gtk--, which I find is a really neat wrapper around Gtk+ (let's me use widgets using a decent language).
I suppose someone ought to go thru the code in the used libraries today, rip things out, and make them run efficiently on the sparc20 which will be the only system they would be allowed to use for the task. For some reason, it seems it's a lot more fun to add new features, than to spend a year wading thru piles of rotten code... Wonder why:)
I develop software for various platforms (including windows) for a living.
I have used Visual Studio. I have my scars.
Anyone claiming that a compiler that understands so little of C++ "kicks ass" shouldn't be shouting "get a clue" to others. That issue aside, let's talk about the environment:
Ever tried running an strace in VC++ ? Ever wanted to make your app fork and coredump in the exception constructor so that you could later on inspect the dump ? No ? For someone who doesn't know what real development environments have to offer, I'm sure that VC++ looks impressive. For a real coder, it's like having your hands cut off.
I am sure that for writing a Windows GUI, VC++ is a fine tool. And I'm sure it kicks a lot more ass than gcc and gdb on a Linux platform would do (given the absence of the Win32 API). But you must not think that writing a GUI or some other toy application is anywhere close to the job of writing a high performance distributed computational application.
You're probably right that there are tools on windows which are nice for developers of certain types of applications. Distributed computing, however, is a special kind of development, and you just can't slap those GUI tools and languages on a cluster and expect it to be productive.
I'm not saying that it can't be done. In fact, I said that it would work just fine for dog and pony shows.
And with enough effort, of course you can do real work on this kind of cluster.
I would be very interested in hearing your oppionion on this: Why did you choose an MS cluster ? I know it's not for the support, not for the tools, not for the environment... Or ? Perhaps you have different experiences from mine - I would like to know about it.
I have worked with supercomputing and clusters for government and private companies for six years - I am not just trolling when I say that "surely people won't pick XXXX". I have good reasons to say what I say - and I am truely curious as to why you seem to have experiences that's so differnet from mine. Please, enlighten me:)
For a computational cluster, the OS itself shouldn't really matter. What matters is, do you have the tools you need, and does the environment allow you to work with the cluster in a flexible way.
For a typical compuatational cluster, what determines the performance will be the quality of your application. Only if you pick an OS with some extremely poor basic functionality (like, horribly slow networking), will the OS have an impact on performance.
People optimize how their application is parallelized (eg. how well it scales to more nodes). The OS doesn't matter in this regard. They optimize how well the simple computational routines perform (like, optimizing an equation solver for the current CPU architecture) - again, the OS doesn't matter.
So, in this light, you might as well run your cluster on Windows instead of Linux, or MacOS, or even DOS with a TCP/IP stack (if you don't need more thatn 640K;)
However, there's a lot more to cluster computing than just pressing "start". You need to look at how your software performs. You need to debug software on multiple nodes concurrently. You need to do all kinds of things that requires, that your environment and your tools will allow you to work on any node of the cluster, flexibly, as if that node was the box under your desk.
And this is why people don't run MS clusters. Windows does not have proper tools for software development (*real* software development, like Fortran and C - VBScript hasn't really made it's way into anything resembling high performance (and god forbid it never will)).
Furthermore, you cannot work with 10 windows boxes concurrently, like they were all sitting under your desk. Yes, I know terminal services exist, and they're nice if you're a system administrator, but they are *far* from being usable to run debuggers and tracing tools on a larger number of nodes, interactively and concurrently.
Last but not least, there are no proper debugging and tracing tools for windows. Yes, they have a debugger, and third party vendors have debuggers too. But anyone who's been thru the drill on Linux (using strace, wc -l/proc/[pid]/maps,...), and needed the same flexibility on windows, knows that there is a world of difference between what vendores can put in a GUI and what you can do when you have a system that was built for developers, by developers.
So sure - for a dog&pony show, windows will perform similar to any other networked OS with regards to computational clusters. But for real-world use ? No, you need tools to work.
Slashdot Mirror
Give a man a fish, and he owes you a favour.
Teach a man to fish, and you lose your monopoly on fishing.
All it takes is a crew that is loyal to that one person.
A few handfulls of minions and an evil genious. (Realistically though, I doubt the person would have to be much of a genious - basic knowledge of "mass" psycohology would go a long way).
And so what? We place trust in the hands of single persons and trust that they do their duties. In the end we're all dead anyway.
It is: cpe1704tks
;)
You never saw War Games, did you ?
The Melissa worm :)
;)
Now thinking about how a proper reference monitor could have been implemented in outlook to completely avoid this worm and all the others, and how these implementations are often just a few hundred lines of code - I vote for the "missing reference monitor" in Outlook to be the most expensive *missing* data out there
(See TCSEC for a description of the reference monitor concept, if you don't know about it)
Then whatever you do, make sure you build your systems on a B1 (or better) certified system, and that it's properly configured.
Take a look at Trusted Solaris. It is by no means a solution in itself, but it is a prerequisite for a moderately secure system.
The idea is, that even if your system is rooted, the intruder will not have access to change system parameters (root is not allmighty), he cannot run standard utilities if he entered via. the network (compartments, mandatory security and trusted paths), and his activities can be logged (auditing).
So you don't use a standard network stack. Instead, you create a communications library and use that in your applications.
How is that different from just using the network stack ?
Granted, it adds a tiny amount of obscurity. But your apps on the front-end will still be using your comms. library, and if I r00t your front-end, I will still be able to talk to the "secure" machine (using your neatly written comms library).
Fundamentally, you change nothing. You add a tiny layer of obscurity, but that's it.
So let me get this straight: You set up an "oracle" (a machine which you can ask to decrypt data and which will do so when asked). Your "security" lies in your "low-level" protocol (for which you obviously have communications code on the front-end machine).
Where's the security in that ?
Let's say I r00ted your front-end machine. Why don't I just look at your script or your binary and see that it sends the request over SCP. Or over a PERL socket reader.
You have added a very tiny amount of obscurity, but nothing that resembles security. Your "oracle" has no way of knowing who's asking, if you built the assumption into the system that "anyone who can ask must be in their good right to know".
Even if it's on a private network on another NIC, this doesn't help one bit. I r00ted your front end machine, remember - if the front end machine can talk to the oracle, so can I, when I'm root on the front end.
You may be able to add a little security resemblence with your "anomaly detection". However, it is quite likely that I am smart enough to just see how valid requests are built, before I try my own requests at the oracle.
So when you crack the server and get root, you need to go *all* the long way to a gdb which you attach to the running process, in order to get the key out.
;)
Wow. Good thing it doesn't get swapped out, then the "print" from gdb might have taken an extra millisecond
It's easy; don't store the information. If it's not there, noone can steal it.
;)
Store the address, name, phone number, visit history, mother's maiden name, shoe size, whatever you want - but don't store the credit card number.
I'm quite happy with entering my credit card information whenever I purchase something. Knowing that this information will not be leaked to the next script kiddie who drops by - you simply cannot trust security at sites with dropping revenues, budget cuts, etc.
Clearly, the number one priority for many business sites today is to keep things running. Security is only a problem if it's broken. And that only happens if you're unlucky... Yearh right...
Am I pessimistic, or are you naiive ?
The URL says it all.
;)
"Fis a'" means "bugger off" in Danish
Does anyone know if an encrypted filesystem is availble for OpenBSD ? Seems like it still isn't. Except for the hacks like CFS... Is there an encrypted filesystem which is ready for *real* use out there ?
Nice try :)
I understand it allright, and I understand what I or anyone else could do messing with those databases. Now, I'm not the kind of person who would do such a thing - but I know what technology does to people who does not understand that it is not infallible.
The technology does not scare me one bit. What scares me, is knowing that *people* will be using the technology.
It's beyond me how anyone would trust their biometrics to random companies (or other entities). Hell, I wouldn't trust the government with mine (they can take prints from my dead cold hands).
The problem is, that they are not just creating a "hash" from your prints - they need to store the exact print in order for the recognition to work. This means, any script kiddie lucky enough to get into their database, will have the prints.
The next logical step is, to hook this system up to the feds and interpol (post sept-11 this is not fiction!)
The real problem will be, that people trust technology blindly. When I "check out" of the store, putting my thumb on the reader, and the alarm bells sound (and the big "armed and dangerous, shoot on sight" sign starts flashing), guards, police, whatever, will trust the damn machine.
Now if one could trust that the responsible parties would (and could) ensure "absolute security" around their biometrics systems, there really wouldn't be that much of a problem. But believing that IT departments in regular companies (or even government agencies) who all live with finite budgets will ensure that their back-end systems are un-crackable is naiive.
Luckily, the iris scanning in the airports is still optional (and actually sold at an extra charge, as some sophisticated "luxury" - hah!).
Please tell me, what the heck *does* \dev\null mean ?
;)
(*back*slash dev *back*slash null - 'nuff said
Am I the only one who thinks it's strange that while we get told about all these fantastic things that can be done which weren't possible a year ago, people still say convincingly that "you can't get the state from the system without leaving finger prints" ?
I'm sure we can't today. And I'm equally sure that someone is going to figure out a way to touch the system so insignificantly that the "reading" cannot be measured.
Like when reading from a hard-drive: Of course the head will alter the state of the platter when passing by - it's just so insignificant that it doesn't matter, and it would probably be hard to measure if anybody tried.
While this is fascinating and all, I just don't buy into the "can't cheat with this one". Many years ago, everyone agreed that you couldn't split an aton - which was natural, because "the atom" itself was a relatively new idea in itself at that time.
I find it hard to believe that the progress stops here.
Did anyone besides me notice, that the windows RDP server *ALWAYS* uses the same prime for the server<->client key negotiation ?
128-bit my arse, if any small government or large company can spend half a year pre-computing attacks for the single prime number that's used in all windows RDP servers.
Goddammit! Read the article...
3250 km^2 surface area
200 m thickness
Volume will be close to surface area * thickness.
3250 [km^2] * (1000 [km/m])^2 = 3250 * 10^6 [m^2]
(3250 * 10^6) [m^2] * 200 [m] = 650 * 10^9 [m^3]
1 m^3 of ice weighs sufficently close to one metric tonne for the purpose of this argument.
Thus: Total weight approx. 650 U.S. billion metric tonnes
Or, 650 * 10^12 kg.
Oh, and ice is approx. 0.9 the density of water, but given the orders of magnitude of the previous inaccuracies, I think that's pretty irrelevant.
The argument that someone else raised, that such a rule could exist because "people might be hanging around Sony's booth only to play games, and not go look at the other exhibitors", simply doesn't hold - for the following reasons.
CeBIT is the largest such exhibition in the world, there are more than 8000 exhibitors, and more than 150.000 visitors each day. You don't just "browse" the exhibition, you plan your visits from home.
The ticket is around $120 - you don't waste a day there just for playing a $40 game.
Sony let people play with their software, and so what ? They let me play with Linux on their PS/2 as well. And being an exhibitor there, I've let people play with our software in our booth as well. Just like Sun let me play with their software, IBM with theirs, etc. etc. etc.
Strange how people seem to believe that a superior force using bigger weapons is going to help against the inferior force that doesn't fight in a way where the size of weapons matter.
Face it - the U.S. is a superior military force today. Using bigger or smaller bombs is not going to make one bit of difference.
The way that other forces fight back, is naturally not by putting up their largest army, only to see it squashed by the bigger army. That would be silly. No, the way to conquor a larger state with your inferior army, is to strike them where they do not expect it. That is why someone used civil aircraft as bombs on Sept. 11th. Whether we like it or not, it's the rational choice (if you can talk about "rational" and "warfare" in the same sentence...).
Now before you condemn what I say here - think about it. If you were at war with a superior force, would you line up in rows and columns to be slaughtered by the superior force, or would you rather be smart and make a difference ?
One thing's certain; using bigger bombs is not going to make fewer people strike back. I fail to see the logic behind this escalation, should it pass.
And no, I do not applaud what's been happening in the world lately. If you think I do, read this post again. Re-iterate as you must.
No way ! I wrote my own widget set on Xlib back in 1996. Real men don't need bloat like Xt ;)
:)
Actually I did. Didn't use anything but Xlib. But it's gone now - you really need a capable and *standard* widget set (eventually comprising dialogs like "file open" etc.) to make apps that are nice (not use usable).
Today I use Gtk--, which I find is a really neat wrapper around Gtk+ (let's me use widgets using a decent language).
I suppose someone ought to go thru the code in the used libraries today, rip things out, and make them run efficiently on the sparc20 which will be the only system they would be allowed to use for the task. For some reason, it seems it's a lot more fun to add new features, than to spend a year wading thru piles of rotten code... Wonder why
I develop software for various platforms (including windows) for a living.
I have used Visual Studio. I have my scars.
Anyone claiming that a compiler that understands so little of C++ "kicks ass" shouldn't be shouting "get a clue" to others. That issue aside, let's talk about the environment:
Ever tried running an strace in VC++ ? Ever wanted to make your app fork and coredump in the exception constructor so that you could later on inspect the dump ? No ? For someone who doesn't know what real development environments have to offer, I'm sure that VC++ looks impressive. For a real coder, it's like having your hands cut off.
I am sure that for writing a Windows GUI, VC++ is a fine tool. And I'm sure it kicks a lot more ass than gcc and gdb on a Linux platform would do (given the absence of the Win32 API). But you must not think that writing a GUI or some other toy application is anywhere close to the job of writing a high performance distributed computational application.
You're probably right that there are tools on windows which are nice for developers of certain types of applications. Distributed computing, however, is a special kind of development, and you just can't slap those GUI tools and languages on a cluster and expect it to be productive.
I'm not saying that it can't be done. In fact, I said that it would work just fine for dog and pony shows.
:)
And with enough effort, of course you can do real work on this kind of cluster.
I would be very interested in hearing your oppionion on this: Why did you choose an MS cluster ? I know it's not for the support, not for the tools, not for the environment... Or ? Perhaps you have different experiences from mine - I would like to know about it.
I have worked with supercomputing and clusters for government and private companies for six years - I am not just trolling when I say that "surely people won't pick XXXX". I have good reasons to say what I say - and I am truely curious as to why you seem to have experiences that's so differnet from mine. Please, enlighten me
For a computational cluster, the OS itself shouldn't really matter. What matters is, do you have the tools you need, and does the environment allow you to work with the cluster in a flexible way.
For a typical compuatational cluster, what determines the performance will be the quality of your application. Only if you pick an OS with some extremely poor basic functionality (like, horribly slow networking), will the OS have an impact on performance.
People optimize how their application is parallelized (eg. how well it scales to more nodes). The OS doesn't matter in this regard. They optimize how well the simple computational routines perform (like, optimizing an equation solver for the current CPU architecture) - again, the OS doesn't matter.
So, in this light, you might as well run your cluster on Windows instead of Linux, or MacOS, or even DOS with a TCP/IP stack (if you don't need more thatn 640K
However, there's a lot more to cluster computing than just pressing "start". You need to look at how your software performs. You need to debug software on multiple nodes concurrently. You need to do all kinds of things that requires, that your environment and your tools will allow you to work on any node of the cluster, flexibly, as if that node was the box under your desk.
And this is why people don't run MS clusters. Windows does not have proper tools for software development (*real* software development, like Fortran and C - VBScript hasn't really made it's way into anything resembling high performance (and god forbid it never will)).
Furthermore, you cannot work with 10 windows boxes concurrently, like they were all sitting under your desk. Yes, I know terminal services exist, and they're nice if you're a system administrator, but they are *far* from being usable to run debuggers and tracing tools on a larger number of nodes, interactively and concurrently.
Last but not least, there are no proper debugging and tracing tools for windows. Yes, they have a debugger, and third party vendors have debuggers too. But anyone who's been thru the drill on Linux (using strace, wc -l
So sure - for a dog&pony show, windows will perform similar to any other networked OS with regards to computational clusters. But for real-world use ? No, you need tools to work.
Is blowing in the wind.
Way to go dude !