absolute flaimbait, as the siblings have seen, but I'll bite.
Though a slim majority of American consider themselves to be Christian and supposedly tout how ethical they are (Can you say, "torture in Abu Ghraib"?), they quickly ascribe the term "Hero" to people -- like Linus, Princess Diana, Mick Jagger, and Magic Johnson -- whose main "achievement" (i.e., accruing money, fame, or beauty) has nothing to do with ethics.
By 'they' you actually mean a couple of editors of TIME magazine. Yes, I'm sure a couple of well-to-do New York snobs represent all our opinions.
What does this have to do with Christianity at all? Just be happy for Linus, who in fact conducts himself with dignity and deserves "pop" recognition for his contributions to computing science and technology.
My initial reaction was also one of "wow, that's stupid", but presumably the bullet is fired by a combination of the firing pin (so, the holder of the weapon still has control) plus the radio signal. So, I don't think that guns will spontaneously go off just b/c someone guessed the right key -- you still need to pull the trigger.
Seen the right way, it's classic two-factor authentication.
I am guessing that the "key or signal" is delivered from a device that is perhaps embedded in the handle to read your fingerprints, RFID tag embedded in your wrist, or some other biometric.
And also one thing I wonder, is what Antivir was "protecting" the machine? Is nt antivir doing heuristics to look after strange things at the computer, like "something" trying to get the addressbook?
Protecting against this type of attack really isn't an AV activity.
Most consumer-level anit-virus software is simply doing misuse detection -- basically string or pattern matching on signatures. The other major category of anomaly-based detection...but this has a much higher false positive rate, even with extensive training. Some AV products perform anomaly detection based on sequences of system calls and other access patterns, but its fundamentally hard to distinguish malicious behavior from merely previously unseen behavior. For example, is having a newly installed Firefox instance access your bookmarks a malicious thing, or is it just a new, one-time use pattern?
I wasn't suggesting "moving bytes around." The binary undergoes a reversible transformation (like XOR with some key). This creates a "new" binary based on a "new" instruction set specific to the key used in the transformation. Then the binary is decoded at runtime with the key. Anything injected into the binary causes an exception (either invalid opcode or invalid memory reference, etc.) The idea is the same whether or not a software system does the execution (an emulator) or the hardware does it (special new chips from Intel).
As the sibling poster says, there is no need to include source or ask people to recompile. The binary can undergo a reversible transformation at installation (or even at load time). Then, during execution, each instruction is essentially decrypted/decoded with the appropriate secret key.
One of the major benefits of instruction set randomization is that you *don't* need the source code or to recompile to get the security benefits.
The only *real* downside is the performance hit (and the fact that it doesn't counter all possible attacks, but then, nothing does.)
Changing hardware to do ISR isn't that difficult; you essentially include another register that holds a secret key that has transformed the binary. During runtime, as an instruction is fetched, it is decoded with the key and then passed to the normal execution machinery.
Since not every university has their own chip fabrication facility, the next most logical choice is to run things in an emulation or binary translation environment. Valgrind itself isn't a debugger, although its most popular tools (Memcheck, etc.) are used as such.
In fact, the general concept of "instruction set" randomization, where instruction set is loosely defined can be broadly applied. In particular, this paper looks at SQL randomization:
An application that has code injected into it will behave differently, becuase the execution environment (i.e., Valgrind in RISE's case) will try to de-randomize the binary (including the injected code). Presumably, de-randomizing the injected code will fail and cause a signal that is visible to the operating system.
So, artificial diversity *does* make it harder to debug a system, but in this case, not really, and the system should save enough state in the alert to let you know where things went wrong.
You are right -- and thus sticks out like a sore thumb. So the grandparent should note: just because you can't read the content doesn't mean that the flow isn't interesting, especially the endpoints.
See this paper [warning: PDF] for content-based analysis of traffic and how encrypted traffic differs quite a lot from normal traffic. Thus, an ISP can simply wait for this type of traffic and kill it (or charge the endpoint extra).
(kidding, I know there are no camels on the US -...)
Not to disappoint you, but I know for a fact that this statement is false. I recently drove from El Paso, TX to Trenton, NJ and did in fact see a herd of camels in Texas (somewhere between Lubbock and Witchita Falls).
The encryption is actually end-to-end, so AOL doesn't have a prayer of intercepting and decoding your conversation, especially if you don't use their client and instead use GAIM and its crypto plugin.
The grandparent post does present a viable solution: the encryption plug in for GAIM creates your own public/private keypair and transmits your public key to other people who contact you. This is exactly what AOL IM client should do, but they want to make money for Verisign, so they tell people to buy certs.
Enter social engineering of aimencrypt.com, creating a bigger problem out of something that shouldn't be a problem in the first place.
SQL is a platform-independent issue. If you are insinuating that there are no mainstream database platforms for Linux, then you've had your head in the sand for a while. Also, 'web' applications are also a non-linux issue. Maybe you're complaining about development environments or IDEs. Let's face it: web application platforms are quite tried and true on Linux: J2EE, and PHP/MySQL to name just two. Have you actually tried any besides MS Visual C++? If you can't find a decent IDE to your liking for Linux, emacs is the good old standby.
I need tools that will help me built solutions
What's wrong with./configure, make, make install, make test?
that runs without recompiles and linking and privilege settings...
Most, if not all applications that I know of need to be re-compiled if you've made changes to the source. And, once compiled, all the Linux apps I know don't need to be recompiled before they are run. Finally, privilege separation and access control provides better security than the default Windows "Administrator for everything" model.
there are no tools available to let me do my job like there are on Linux.
I know you meant to say "Windows" for that list bit, but I couldn't resist...perhaps a Freudian slip on your part?
In any event, there are other reasons to use Linux -- but if you are looking for a cozy user experience alone, go try Mac OS X.
And I realize you were being funny... but for those folks who don't understand you were talking about the virus-writers, I felt obligated to point out that WINE is quite useful.
Yes, it is a solution. Especially in situations where you have persuaded your friends and relatives to use Linux, but they still want to use some crappy Windows software because they are used to it, and there are no free/open-source ones.
Furthermore, the 2% of Linux users don't really constitute a meaningful profit motive for these companies. We need to do more to get Linux on the desktop before they'll jump off the MS ship.
I agree. A reasonably sized corporation would have the capability to do this, much like the porn web filters that are widely deployed.
For this particular usage scenario, it's an arms race -- certainly the company would find it easier to implement a blanket policy: no outgoing PGP encrypted email from any of our serfs. Implementing a targeted policy means that you have to get the word from the higher-ups down to the mail admins. If you (whistleblower, guy about to get canned, etc.) have been leaking info for months, then they only stop the last few transmissions you attempt.
In any event, there are other usage scenarios where encrypted email for everyday folk is quite useful.
And if it's storing your password on the disk as well as the obligatory keys...
Presumably you'd be sending it to a non-company e-mail account. Your secrets would be stored on the client that is meant to receive this e-mail.
If you're just sending something encrypted, you don't need to enter a passphrase (the e-mail is encrypted with the public key of the recipient) -- the recipient (in this case, presumably your "home" email address) enters a passphrase. The worst they can do is see that you signed a particular message...
read their mail instantly than have to bother remembering yet another password
A valid point. However, the gain may be worth the extra headache -- and since most POP clients already store your login password on disk and 'remember' it for you, storing a PGP passphrase would be no great trouble. If everyone had their own user account and this on-disk password was adequately protected, no big deal.
The point is to protect the communication in transit: consider someone emailing legal documents to their lawyer and other such scenarios. Or someone who is about to get canned from the company and wants to export evidence about bad practices or job discrimination. Sure they could use SFTP, but how many users actually have servers they can send stuff to? It is far easier to encrypt it and mail it to your home account, and the employer really can't detect that as abnormal.
So yes, encrypted email does have uses for joe and jane 30-pack. And I'd bet it's even more useful with things like the Patriot Act in existence.
Since the author of the virus actually is the owner of the copyright on the viral code, then the encryption should qualify as a copyright protection device under the DMCA
That's an interesting thought. I'd imagine at some point the virus would have to decrypt itself and then could be legally captured by some piece of monitoring software. An interesting technical challenge resulting from a "creative" use of the law.
Slashdot Mirror
Though a slim majority of American consider themselves to be Christian and supposedly tout how ethical they are (Can you say, "torture in Abu Ghraib"?), they quickly ascribe the term "Hero" to people -- like Linus, Princess Diana, Mick Jagger, and Magic Johnson -- whose main "achievement" (i.e., accruing money, fame, or beauty) has nothing to do with ethics.
By 'they' you actually mean a couple of editors of TIME magazine. Yes, I'm sure a couple of well-to-do New York snobs represent all our opinions.
What does this have to do with Christianity at all? Just be happy for Linus, who in fact conducts himself with dignity and deserves "pop" recognition for his contributions to computing science and technology.
Seen the right way, it's classic two-factor authentication.
I am guessing that the "key or signal" is delivered from a device that is perhaps embedded in the handle to read your fingerprints, RFID tag embedded in your wrist, or some other biometric.
Protecting against this type of attack really isn't an AV activity.
Most consumer-level anit-virus software is simply doing misuse detection -- basically string or pattern matching on signatures. The other major category of anomaly-based detection...but this has a much higher false positive rate, even with extensive training. Some AV products perform anomaly detection based on sequences of system calls and other access patterns, but its fundamentally hard to distinguish malicious behavior from merely previously unseen behavior. For example, is having a newly installed Firefox instance access your bookmarks a malicious thing, or is it just a new, one-time use pattern?
I wasn't suggesting "moving bytes around." The binary undergoes a reversible transformation (like XOR with some key). This creates a "new" binary based on a "new" instruction set specific to the key used in the transformation. Then the binary is decoded at runtime with the key. Anything injected into the binary causes an exception (either invalid opcode or invalid memory reference, etc.) The idea is the same whether or not a software system does the execution (an emulator) or the hardware does it (special new chips from Intel).
One of the major benefits of instruction set randomization is that you *don't* need the source code or to recompile to get the security benefits.
The only *real* downside is the performance hit (and the fact that it doesn't counter all possible attacks, but then, nothing does.)
Since not every university has their own chip fabrication facility, the next most logical choice is to run things in an emulation or binary translation environment. Valgrind itself isn't a debugger, although its most popular tools (Memcheck, etc.) are used as such.
http://www1.cs.columbia.edu/~angelos/Papers/sqlran d.pdf
and this paper also looks at instruction set randomization, and randomizing Perl:
http://www1.cs.columbia.edu/~angelos/Papers/instru ctionrandomization.pdf
A similar paper is here: http://www1.cs.columbia.edu/~angelos/Papers/instru ctionrandomization.pdf (in fact, they both appeared at CCS a couple of years ago) and the basic idea is that the use of the 'new' instruction set is completely transparent to a well-behaved application.
An application that has code injected into it will behave differently, becuase the execution environment (i.e., Valgrind in RISE's case) will try to de-randomize the binary (including the injected code). Presumably, de-randomizing the injected code will fail and cause a signal that is visible to the operating system.
So, artificial diversity *does* make it harder to debug a system, but in this case, not really, and the system should save enough state in the alert to let you know where things went wrong.
See this paper [warning: PDF] for content-based analysis of traffic and how encrypted traffic differs quite a lot from normal traffic. Thus, an ISP can simply wait for this type of traffic and kill it (or charge the endpoint extra).
They looked like they had been domesticated. Perhaps 'domesticated' is the wrong word -- they were in a fenced-in pasture.
As we cruised over a small hill, my friend and I turned to look at each other: "Did we just see camels?"
Well, they sure looked like camels.
Not to disappoint you, but I know for a fact that this statement is false. I recently drove from El Paso, TX to Trenton, NJ and did in fact see a herd of camels in Texas (somewhere between Lubbock and Witchita Falls).
The encryption is actually end-to-end, so AOL doesn't have a prayer of intercepting and decoding your conversation, especially if you don't use their client and instead use GAIM and its crypto plugin.
Enter social engineering of aimencrypt.com, creating a bigger problem out of something that shouldn't be a problem in the first place.
Have someone they trust fold different notes in different ways and load up the wallet or billfold.
I hope it includes a cup for sensitive areas. I am uncomfortable with the idea of space rocks impacting my organs.
On that note, I guess that's why I'm a geek and am not qualified to actually explore space.
As a developer (c/s, web, SQL, etc)
SQL is a platform-independent issue. If you are insinuating that there are no mainstream database platforms for Linux, then you've had your head in the sand for a while. Also, 'web' applications are also a non-linux issue. Maybe you're complaining about development environments or IDEs. Let's face it: web application platforms are quite tried and true on Linux: J2EE, and PHP/MySQL to name just two. Have you actually tried any besides MS Visual C++? If you can't find a decent IDE to your liking for Linux, emacs is the good old standby.
I need tools that will help me built solutions
What's wrong with ./configure, make, make install, make test?
that runs without recompiles and linking and privilege settings...
Most, if not all applications that I know of need to be re-compiled if you've made changes to the source. And, once compiled, all the Linux apps I know don't need to be recompiled before they are run. Finally, privilege separation and access control provides better security than the default Windows "Administrator for everything" model.
there are no tools available to let me do my job like there are on Linux.
I know you meant to say "Windows" for that list bit, but I couldn't resist...perhaps a Freudian slip on your part?
In any event, there are other reasons to use Linux -- but if you are looking for a cozy user experience alone, go try Mac OS X.
And I realize you were being funny ... but for those folks who don't understand you were talking about the virus-writers, I felt obligated to point out that WINE is quite useful.
Furthermore, the 2% of Linux users don't really constitute a meaningful profit motive for these companies. We need to do more to get Linux on the desktop before they'll jump off the MS ship.
I agree. A reasonably sized corporation would have the capability to do this, much like the porn web filters that are widely deployed.
For this particular usage scenario, it's an arms race -- certainly the company would find it easier to implement a blanket policy: no outgoing PGP encrypted email from any of our serfs. Implementing a targeted policy means that you have to get the word from the higher-ups down to the mail admins. If you (whistleblower, guy about to get canned, etc.) have been leaking info for months, then they only stop the last few transmissions you attempt.
In any event, there are other usage scenarios where encrypted email for everyday folk is quite useful.
And if it's storing your password on the disk as well as the obligatory keys...
Presumably you'd be sending it to a non-company e-mail account. Your secrets would be stored on the client that is meant to receive this e-mail.
If you're just sending something encrypted, you don't need to enter a passphrase (the e-mail is encrypted with the public key of the recipient) -- the recipient (in this case, presumably your "home" email address) enters a passphrase. The worst they can do is see that you signed a particular message...
A valid point. However, the gain may be worth the extra headache -- and since most POP clients already store your login password on disk and 'remember' it for you, storing a PGP passphrase would be no great trouble. If everyone had their own user account and this on-disk password was adequately protected, no big deal.
The point is to protect the communication in transit: consider someone emailing legal documents to their lawyer and other such scenarios. Or someone who is about to get canned from the company and wants to export evidence about bad practices or job discrimination. Sure they could use SFTP, but how many users actually have servers they can send stuff to? It is far easier to encrypt it and mail it to your home account, and the employer really can't detect that as abnormal.
So yes, encrypted email does have uses for joe and jane 30-pack. And I'd bet it's even more useful with things like the Patriot Act in existence.
That's an interesting thought. I'd imagine at some point the virus would have to decrypt itself and then could be legally captured by some piece of monitoring software. An interesting technical challenge resulting from a "creative" use of the law.
Nice idea, but tough in practice.
Hmmm...
'root', naturally... just make sure everyone has the password written down in a memorable place.