That's why OpenBSD allows you to encrypt your swap.
Provos wrote this in 2001: Encrypting Virtual Memory
The new scientist sort of misrepresented the findings of the paper. The fact that passwords and other sensitive information gets retained on swap for a long time. The paper was looking at memory tainting, i.e. if an application handles a password where does it end up in memory. The results were slightly surprising.
Nontheless, most people would be even more surprised to see how much sensitive information ends up in swap. That's why you want to encrypt your swap partition.
It is unforunate that you spread such misinformation. Clearly, you know neither the Flask microkernel to which
the whitepaper refers nor systrace.
The flask paper has a one paragraph argument against system call interposition. Basically the time of check is not the time of use and there may be different names to address the same resource, in other word aliasing problems.
These are valid arguments that show problems for a system call interposition tool.
However, Systrace is a hybrid system, it has parts in the kernel that allow it to get whatever additional control it requires. Aliasing is not an issue in practise because resource names
can be normalized and the remaining aliasing problems are merely hyptothetical. The same goes for the TOCTOU argument. In practise, you can ensure that such race conditions are not relevant.
But let me ask you another question. Have you ever used a system that is based on Flask? Or do you know anyone who has?
On the other hand, Systrace is available for GNU/Linux, Mac OS X, NetBSD and OpenBSD.
No Open Source implementation because of Patent?
on
VRRP
·
· Score: 3, Interesting
From reading the web, it seems that no open source implementation is possible unless a license has been obtained from Cisco.
I am not aware of any open source project that has ships VRRP. The IETF has received more information from Cisco about their Intellectual Possession in regards to VRRP.
Lately, I have been puzzling about the security of my web passwords. As a result, I wrote a little perl script that derives passwords from a strong master password. Something like this:
$ key.pl
Password:
Website: slashdot.org
Password for slashdot.org:
llynUngiltBerneLobal
Lately, we have seen many trojaned distributions. To prevent
these problems from affecting us in the future, we need to
use cryptographic signatures as part of software distribution.
Otherwise, we never know if a particular piece of software is
authentic or not. Signature checking needs to be part of the
installation process. I believe that Debian's aptget is one
of the few tools that actually does this.
In the meanwhile, I suggest that you run all your untrusted
software in a sandbox like Systrace which is available for the BSDs and Linux.
This
screenshot shows Dug Song detecting the trojan in the Fragroute distribution. Systrace allows
you to run completely untrusted applications in a sandbox. The security
policy is created on the fly with the user deciding what an application
is allowed to do.
We need to be much more careful about the software that we run.
Isn't this "Privilege Elevation" really just an implementation of capabilities? Given the proper capability token, the program can now access a particular priveleged resource (eg syscall).
Regular capability systems are more coarse grained. You can have capabilities that say this application is allowed to bind to a reserved port,etc.
However, with privilege elevation in systrace, you have much finer control. The privileges are just elevated for a single system call matching specified system call arguments.
Additionally, with systrace you can reduce the privileges of binary applications without the need to add support for capabilities in the source code.
For system services that change privileges based on some internal state (like authentication), sandboxing does not work very well.
In that case, you want to use Privilege Separation.
On the other hand, if you have some global restrains, like root may never log in, you can use systrace to enforce them.
A combination of both methods will give you a good fit.
This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.
At least for content management systems, there is a very solid CVS replacement:
Please take a look at http://anti.security.is when you have some spare time.
anti.security.is is a place for disinformation. Everybody knows that. Just try to follow their arguments, and you will see that it is not sound. With an incorrect premiss, you can derive whatever you like.
Besides, the cycle that they are describing is exactly how security research works. People who fix, and people who break. Working together to improve your security.
Full disclosure is where the script kiddies get their tools.
Now this is public knowledge, an exploit will be available within hours.
You do not know what you are talking about. Full disclosure has greatly improved security awareness and turn around time for fixes. If you want to turn your back on full disclosure, you are heading back into the middle-ages of computer security.
This should have been fixed before it was announced, and a period of time waited for people to upgrade.
The information was leaked by someone who jumped the gun. That is the reason why the
relase and advisory happened today instead of Monday. Nothing to be done about it. Instead
of bitching, fix a bug in your operating system and send a patch to the developers. Much more useful behaviour for all of us.
Of course, you should be running
with
ln -s AJ/etc/malloc.conf
anyway. It will fill freed memory with junk,
and quite often finds conditions where memory
is referenced after it has been freed.
In that case, there is no problem anyway. If your operating system of choice has not support for malloc debugging, looby
your developers, it is a very useful feature.
The 32 bytes of the first level challenge consists of a string of zeros.
The 256 bytes of the second level challenge consists of white noise.
I hope that you will not get called on that.
Many steganographic systems leave signatures
and header information in the images that are completely independent of the data that you hide.
That means you can detect such a steganographic system without knowing anything about the hidden data.
Furthermore, white noise in terms
of randomness is something detectable, too.
Most images do not exhibit random noise in
their lower layers.
There is a paper by Westfeld and Pfitzmann that shows visual attacks that depend on the
fact that steganographic systems leave white
noise behind destroying visual structures in
the lower layers.
I am bit surprised. I released stegdetect
in early February this year. It automatically detects steganographic content in images. It can even determine which program was used to embed hidden content.
You might also want to check the techreports
that I published about my research.
The truth is, it probably isn't possible to invent the perfect 'undetectable' steganographic procedure for non-random information. [...]
You simply needs to make detection several orders of magnitude more difficult in order to realize a significant benefit.
You should check out stegdetect. It is an automated tool that detects
steganographic content in images. So far it can detect jsteg, jphide and outguess 0.13b. No user interaction, just run it and see the results.
Anybody ever heard of md5sum? Napster really needs to provide an md5sum utility on their servers and clients so they can tell which ones are legit (by sharing the correct md5sum value).
This is exactly the right solution. It is so obvious. The name of a file does not have to correspond with the actual content.
The Napster protocol needs to be extended to actually include a label that describes the content, commonly that is done with a cryptographically strong hash function.
The result of a search would then group files with the same hash value together. It would display the number of files that were found with the same hash value and the different names that were attached to it. The user could than choose from where he wants to download the file. That would not only solve the problem of differences in file names and it would also attach a weight to each entry.
The more files you get with the same hash value, the more likely it is that the content is actually genuine.
I am surprised that this is not already part of Napster. I have been talking about this for many month already.
I am like many people. I like to try before I buy. At the time I had only a 33.6K dialup, I was NOT going to download individual distros. I wanted to burn a CD at work (where I have no bandwidth) then install on my computer at home. I will NOT use their product because of the actions of their spokesperson.
It is amazing how you always resort to the same argument. Where is the problem with burning a CD that contains the install packages that you need, and then use the installation floppy and the burned CD for your installation at home.
You do not require an ISO image for that. Think before you flame. If you have bandwidth at work, you should try to use it intelligently.
Your argument that you "want to try before you buy," and that OpenBSD doesn't allow you to do that because there is no ISO image is flawed. This has been pointed out to you many times before. So, please stop whining. If you can not code, you should try to write documentation.
Why stop there? Let's encrypt everything to the point of all we get on our screen will be a bunch of useless characters. We won't know what is going on, but the important part is neither will THEY! Encode our swap space, maybe that is exactly what they want us to do. Ever think about that?
The idea is to prevent leakage of passwords or other secrets, like your private RSA keys for ssh.
Additionally, once you start using cryptographic file systems, you do not want all your precious secrets to appear as plaintext in the swap partition. From that point of view, encrypting your swap partition makes a lot of sense. You might actually say that you can not securely use a cryptographic file system, when you have unencrypted swap space.
And zeroing out the swap partition is way too expensive. It is also not possible to reliably delete data, check the literature on that.
Steganography is actually a field that has received more attention from research in the last few years. The Information Hiding Workshop comes to mind.
Information Hiding Techniques for Steganography and Digital Watermarking by Katzenbeisser and Petitcolas is a book that has just been published last year and contains a lot more detailed technical information. However, Disappearing Cryptography is at least an amusing book to read.
There is also a bunch of software out there that can be used to embed hidden information into images and sound files. However, most of the programs can be detected. Read the paper by
Westfeld and Pfitzmann, "Attacks on Steganographic Systems".
I myself have written a tool to hide data into JPEGs. It's called OutGuess.
Slashdot Mirror
Provos wrote this in 2001: Encrypting Virtual Memory
The new scientist sort of misrepresented the findings of the paper. The fact that passwords and other sensitive information gets retained on swap for a long time. The paper was looking at memory tainting, i.e. if an application handles a password where does it end up in memory. The results were slightly surprising. Nontheless, most people would be even more surprised to see how much sensitive information ends up in swap. That's why you want to encrypt your swap partition.
The flask paper has a one paragraph argument against system call interposition. Basically the time of check is not the time of use and there may be different names to address the same resource, in other word aliasing problems.
These are valid arguments that show problems for a system call interposition tool. However, Systrace is a hybrid system, it has parts in the kernel that allow it to get whatever additional control it requires. Aliasing is not an issue in practise because resource names can be normalized and the remaining aliasing problems are merely hyptothetical. The same goes for the TOCTOU argument. In practise, you can ensure that such race conditions are not relevant.
But let me ask you another question. Have you ever used a system that is based on Flask? Or do you know anyone who has?
On the other hand, Systrace is available for GNU/Linux, Mac OS X, NetBSD and OpenBSD.
I am not aware of any open source project that has ships VRRP. The IETF has received more information from Cisco about their Intellectual Possession in regards to VRRP.
$ key.pl
Password:
Website: slashdot.org
Password for slashdot.org:
llynUngiltBerneLobal
Its fairly useful on a day to day basis.
In the meanwhile, I suggest that you run all your untrusted software in a sandbox like Systrace which is available for the BSDs and Linux.
This screenshot shows Dug Song detecting the trojan in the Fragroute distribution. Systrace allows you to run completely untrusted applications in a sandbox. The security policy is created on the fly with the user deciding what an application is allowed to do.
We need to be much more careful about the software that we run.
Regular capability systems are more coarse grained. You can have capabilities that say this application is allowed to bind to a reserved port,etc. However, with privilege elevation in systrace, you have much finer control. The privileges are just elevated for a single system call matching specified system call arguments.
Additionally, with systrace you can reduce the privileges of binary applications without the need to add support for capabilities in the source code.
For system services that change privileges based on some internal state (like authentication), sandboxing does not work very well. In that case, you want to use Privilege Separation.
On the other hand, if you have some global restrains, like root may never log in, you can use systrace to enforce them.
A combination of both methods will give you a good fit.
At least for content management systems, there is a very solid CVS replacement:
OpenCM.
One of the many features of OpenCM is cryptographic integrity protection.
Go, read their webpage.
anti.security.is is a place for disinformation. Everybody knows that. Just try to follow their arguments, and you will see that it is not sound. With an incorrect premiss, you can derive whatever you like.
Besides, the cycle that they are describing is exactly how security research works. People who fix, and people who break. Working together to improve your security.
Now this is public knowledge, an exploit will be available within hours.
You do not know what you are talking about. Full disclosure has greatly improved security awareness and turn around time for fixes. If you want to turn your back on full disclosure, you are heading back into the middle-ages of computer security.
This should have been fixed before it was announced, and a period of time waited for people to upgrade.
The information was leaked by someone who jumped the gun. That is the reason why the relase and advisory happened today instead of Monday. Nothing to be done about it. Instead of bitching, fix a bug in your operating system and send a patch to the developers. Much more useful behaviour for all of us.
Of course, you should be running with ln -s AJ /etc/malloc.conf
anyway. It will fill freed memory with junk,
and quite often finds conditions where memory
is referenced after it has been freed.
In that case, there is no problem anyway. If your operating system of choice has not support for malloc debugging, looby
your developers, it is a very useful feature.
The 256 bytes of the second level challenge consists of white noise.
I hope that you will not get called on that. Many steganographic systems leave signatures and header information in the images that are completely independent of the data that you hide. That means you can detect such a steganographic system without knowing anything about the hidden data.
Furthermore, white noise in terms of randomness is something detectable, too. Most images do not exhibit random noise in their lower layers.
There is a paper by Westfeld and Pfitzmann that shows visual attacks that depend on the fact that steganographic systems leave white noise behind destroying visual structures in the lower layers.
You might also want to check the techreports that I published about my research.
At HAL 2001, I presented on Detecting Steganographic Content on the Internet. You might like that.
Dartmouth certainly seems to know how to do PR. I would just like to know where their publications are.
You should check out stegdetect. It is an automated tool that detects steganographic content in images. So far it can detect jsteg, jphide and outguess 0.13b. No user interaction, just run it and see the results.
This is exactly the right solution. It is so obvious. The name of a file does not have to correspond with the actual content.
The Napster protocol needs to be extended to actually include a label that describes the content, commonly that is done with a cryptographically strong hash function.
The result of a search would then group files with the same hash value together. It would display the number of files that were found with the same hash value and the different names that were attached to it. The user could than choose from where he wants to download the file. That would not only solve the problem of differences in file names and it would also attach a weight to each entry.
The more files you get with the same hash value, the more likely it is that the content is actually genuine.
I am surprised that this is not already part of Napster. I have been talking about this for many month already.
Let's hope that we see Napster thrive.
It is amazing how you always resort to the same argument. Where is the problem with burning a CD that contains the install packages that you need, and then use the installation floppy and the burned CD for your installation at home.
You do not require an ISO image for that. Think before you flame. If you have bandwidth at work, you should try to use it intelligently.
Your argument that you "want to try before you buy," and that OpenBSD doesn't allow you to do that because there is no ISO image is flawed. This has been pointed out to you many times before. So, please stop whining. If you can not code, you should try to write documentation.
The idea is to prevent leakage of passwords or other secrets, like your private RSA keys for ssh.
Additionally, once you start using cryptographic file systems, you do not want all your precious secrets to appear as plaintext in the swap partition. From that point of view, encrypting your swap partition makes a lot of sense. You might actually say that you can not securely use a cryptographic file system, when you have unencrypted swap space.
And zeroing out the swap partition is way too expensive. It is also not possible to reliably delete data, check the literature on that.
Information Hiding Techniques for Steganography and Digital Watermarking by Katzenbeisser and Petitcolas is a book that has just been published last year and contains a lot more detailed technical information. However, Disappearing Cryptography is at least an amusing book to read.
There is also a bunch of software out there that can be used to embed hidden information into images and sound files. However, most of the programs can be detected. Read the paper by Westfeld and Pfitzmann, "Attacks on Steganographic Systems".
I myself have written a tool to hide data into JPEGs. It's called OutGuess.
You can find more software here.