Case in point: "someone may use a keystroke logger to find out what your passphrase is". How the fuck is this a Winzip vulnerability?
It isn't a WinZip vulnurability, but it is mentioned in the WinZip documentation. The exact quote from the article is:
For example, as noted in the WinZip documentation, an adversary might try to capture a user's passphrase by installing a keyboard logger on the user's computer or might try to resurrect a plaintext file from memory.
But the above is not the major point, it is mostly an introduction to the next point about how missing integrity of self extracting archives can be used. If you rely on self extracting archives, the archive could easilly carry the key logger into your system. So their point really is, that self extracting archives cannot be secure.
And nobody leaves their BT clients open longer than it takes to download a file
I did when downloading FC1. Actually I had forgotten it was running and didn't terminate it until a few days later asked by a system administrator where this BT traffic was comming from. I think their strategy sounds good. The first few days a lot of people is going to download it, so bittorrent is a good choice. And by waiting a few days before opening the HTTP/FTP servers for the public, they get more people using bittorrent and have bandwidth to get it to the mirrors. Of course there will be load on the mirrors when that version is available. But as soon as the load on the mirrors start to decrease you might want to download it that way instead of through bittorrent. Anybody who wants to wait a month or longer before downloading probably isn't going to use bittorrent, but by that time there shouldn't be as much load on the mirrors. There are only two things I'm wondering about. Why doesn't Fedora include the bittorrent client? And why don't they make updates available for download with bittorrent? When a large security update is announced, it is very hard to get a connection to the server.
This is a VERY SPECIFIC method of USING translucent windows. Not just "a patent on translucent windows."
Just to sumarize, the idea of translucent windows certainly isn't new. People have tried doing something that would resemble translucent windows. But because of performance considerations and limitations in the graphics system used, the result wasn't perfect. But I think even a nonperfect implementation would qualify as prior art as far as the idea is concerned. Had the patent been about a specific algorithm to implement translucent windows more efficiently, it would certainly have made sense. Actually I think what it takes to make efficient translucent windows is hardware, not software. So I have mentioned two things the patent could have been about: The idea of using translucent windows or an efficient way to implement them. But it turns out there is really a third option, the patent is actually about an application of translucent windows. AFAIK there are some minimum requirements to patents, you shouldn't be able to patent something obvious. And personally I think the efficient translucence is a better invention than some application of it.
Obviously this attack requires physical access to the machine. And with physical access to the machine there are easier ways to extract keys. So this is really only relevant if you want to protect against somebody with physical access, that wouldn't perform a simpler attack, which could involve disassembling the machine. I think some chipcards you would use to protect keys is a case, where you might worry about such attacks. But how much noise does a chipcard produce, I think with those it would make more sense to meassure the power consumption. Where are the other cases, where you really need to worry about this?
Nope, for it's DSA/DSS all the way, and all the noisy capacitors in the world won't help you break it.
That wouldn't change anything. RSA as well as DSS is based on modulus exponentiation with a secret exponent. If you can get the exponent you have broken the system, it is as simple as that.
Why do I trust it? Because it was developed by the NSA, not a bunch left leaning MIT eggheads.
That kind of logic is useless in the security business. Basing your trust upon who designed the algorithm is stupid. How many (and who) tried to break the algorithm and failed at that is a better meassure on the security. A good rationale behind the design is another good meassure on the security. And finally mathematical proofs.
That is almost what I would have said. But it still is a bit too simplified. Yes, suid/sgid programs can be insecure, but how insecure of course depends on the owner user/group. For example if you install a game, and the executable is sgid to a special game group to get permission to write to a highscore file, I don't consider that particular insecure. Of course there is the theoretical problem that one user might exploit a bug in the game to be able to overwrite the highscore file with some garbage. This is even worse, if he can exploit another bug in the program to take control of the game when it reads a corrupt highscore file, and that way take control of another user's account. But a bug that can be exploited by a corrupt file could exist in any program also if it was not suid/sgid, and it will only affect users who run the program.
Of course suid root executables are always dangerous, and shouldn't be installed unless you need them. But that is not all. A package can potentially be dangerous even if it does not contain suid/sgid executables. For example device inodes with wrong permissions could be a problem. Device inodes should only be installed by the base system, I would stay far away from any other package installing one. Finally there are a few directories in which installing files can be dangerous, because you automatically load files from those directories. I don't know about BSD, but Linux will automatically load drivers from/lib/modules when needed. So any package installing object files in/lib/modules could be a security problem, even if they are just drivers for a device you don't have on your system. Another example would be if a package installed something in your PATH, which you might run when you didn't intend to. Imagine if a package installed a/usr/bin/ls file, which you executed when you intended to use/bin/ls.
It would be nice with a tool that could check a package for potentially dangerous things, and tell you if it was perfectly safe to install or if it could potentially be a problem. Still I'm afraid if such a tool was created, people would put too much faith in it and expect it to even warn them about potential trojans, which is an entirely different story.
I always write the abbreviated month name instead of a number, and I write the year with four digits. That avoids all that confusion. If you want as much confusion as possible write all three with two digits each. Like 060507 or 030102, and nobody will be sure what date I'm thinking about. Seriously a date with month name and four digits in the year is easy to handle in software if you give it just a bit of thought. If users type in years with just two digits (and users should be allowed to do that), immediately convert the year to four digits and show it to the user, and always store it with the full four digits.
Yes, I agree with that. Secret sharing is the way to go if you have some secret you want to be revealed after your death. I have thought about doing something like this, but when I think about it, what secrets do I have that I really want to be revealed? If all of my disk was encrypted I should surely secret share the key. But I only encrypt a few things, and I encrypt those for a reason. For example you wouldn't want anybody to be able to decrypt your GPG signature and forge your electronic signature after you have died. There might be other things you wouldn't want to be revealed even after your death. Of course there might be good reason a few specific informations should be revealed. For example you could write your will on the computer. Then you print one version sign it with a pen, and treat it like any normal person would treat a will. In addition you put an electronic signature on the will, and put it in your encrypted to_be_opened_after_my_death folder. For which you have already secret shared the key. There might be other things to put in that folder like for example a signed message to be published on usenet, and other places where people should know about your death, but are not close enough to you to automatically get to know. Writing a will is a good idea. I haven't done it myself though, but I know to whom I would testament all my digital storage media. It should be someone you trust to use the data in a reasonable way, and who also have the technical competence to do so.
I don't mind if there are a few ads on the website I'm looking at. As long as it doesn't destroy the content. When it gets too much people will start disabling it. So the trick advertisers should learn is to place as many ads they can without annoying people.
A few examples of ads going too far:
Ads using a significant amount of the bandwidth
Animations
Extremely large pictures
Ads covering parts of the text you want to read
Popup windows
Some ads have annoyed me enough to actually do something about it. And when I first got started with removing ads, I figured I might as well remove some more of them.
I can understand why people discuss how this particular system is implemented. It is not perfectly clear from their explanation. And there are many wrong ways to do it. From their (poor quality) screenshot, it looks like you need to use a webbrowser to login. Not that I understand why they even want people to login, it is a free service, they could just let people use it without any kind of login. Seems it is all done with some kind of javascript, though I'm not absolutely sure that is the case.
It looks like they might think IE is the only application people would ever think about using. In that case they are wrong, if I was ever going to use this system, it would be to run ssh. Will it work only with IE or can any browser be used? Of course IE is required it could be run under wine or VMWare, or you might even reverse engineer the system. Of course once you get it working hiding the ads would be trivial, run the browser under Xvnc for example.
X & video driver didn't install properly (but I fixed it).
That also happened to me when I installed RH6.0 for the first time.
USB scrolling mouse (logitech) didn't install properly (but I fixed it as well).
Interesting with Red Hat Linux 9 and Fedora Core 1 it has worked out of the box under X. But unfortunately it is completely broken under gpm. And by completely broken I mean it was so bad, that it would have been better if it had not worked at all. I have never heard about anybody who got it working.
I couldn't get the sound card to work.
I have tried that as well. My first kernel hack ever was to get ALS120 working under Linux.
Yes, Gentoo is one of them. But there are others Source Mage for example. But a bootable self contained system is more than just bzip2 and a compiler. You need, kernel, libraries, a shell, various command line utils, make, binutils, linker, compiler, etc. When it is all there we are talking about multiple MB. Do you really want to have to download nine copies of this when you only need one of them?
Anyone else noticed, that at first the article linked to a picture which wasn't very good. But a short while after the article came on slashdot they swapped around two of the pictures on the server, such that now the link point to a better picture of their sign. DSCF0023.JPGDSCF0033.JPG
VPN over TCP will give you performance problems. In fact any tunnel device over TCP will give you performance problems. It is the two instances of TCP in the protocol stack that is responsible for most of the problems. Any VPN system built on TCP is broken, it should be build on UDP.
I'd like to 3DES with SHA3 authentication headers which is generally slow to begin with.
3DES is three times as slow as DES, and it is not three times as secure. While the key size has been increased, it still use the same small 64-bit blocks. For that reason I advice against using the same key for more than 512KB of data. 128 bit AES is probably more secure than 3DES, and AES is as fast as DES.
I don't see any reason why it should be slow. You might lose 10% of the bandwidth because of extra headers, but other than that a good implementation should perform just fine. (I admit my own implementation is not yet a good one).
For now I don't. Most of my traffic is ssh anyway. And BTW it is possible to send packets directly between two computers between different NAT boxes. It is tricky, but it can be done. I have written some p2p tunneling software, that does it with UDP packets.
One to take over a running server, and one to elevate to root
In many cases a worm could start spreading without first gaining root priveleges. AFAIR the slapper worm worked like that. But it doesn't do much harm. You can just shut down the vulnurable server and kill the worm process to clean your system. Of course you also have to install the patch before starting the server again.
Ha. I have a linux laptop behind a linux iptables NAT box behind another linux iptables NAT box. The NAT boxes are running two different distributions. Beat that if you can.
Slashdot Mirror
It isn't a WinZip vulnurability, but it is mentioned in the WinZip documentation. The exact quote from the article is: But the above is not the major point, it is mostly an introduction to the next point about how missing integrity of self extracting archives can be used. If you rely on self extracting archives, the archive could easilly carry the key logger into your system. So their point really is, that self extracting archives cannot be secure.
And nobody leaves their BT clients open longer than it takes to download a file
I did when downloading FC1. Actually I had forgotten it was running and didn't terminate it until a few days later asked by a system administrator where this BT traffic was comming from. I think their strategy sounds good. The first few days a lot of people is going to download it, so bittorrent is a good choice. And by waiting a few days before opening the HTTP/FTP servers for the public, they get more people using bittorrent and have bandwidth to get it to the mirrors. Of course there will be load on the mirrors when that version is available. But as soon as the load on the mirrors start to decrease you might want to download it that way instead of through bittorrent. Anybody who wants to wait a month or longer before downloading probably isn't going to use bittorrent, but by that time there shouldn't be as much load on the mirrors. There are only two things I'm wondering about. Why doesn't Fedora include the bittorrent client? And why don't they make updates available for download with bittorrent? When a large security update is announced, it is very hard to get a connection to the server.
Maybe it just means nothing?
;-)
Something we as regular slashdot readers should be used to by now.
This is a VERY SPECIFIC method of USING translucent windows. Not just "a patent on translucent windows."
Just to sumarize, the idea of translucent windows certainly isn't new. People have tried doing something that would resemble translucent windows. But because of performance considerations and limitations in the graphics system used, the result wasn't perfect. But I think even a nonperfect implementation would qualify as prior art as far as the idea is concerned. Had the patent been about a specific algorithm to implement translucent windows more efficiently, it would certainly have made sense. Actually I think what it takes to make efficient translucent windows is hardware, not software. So I have mentioned two things the patent could have been about: The idea of using translucent windows or an efficient way to implement them. But it turns out there is really a third option, the patent is actually about an application of translucent windows. AFAIK there are some minimum requirements to patents, you shouldn't be able to patent something obvious. And personally I think the efficient translucence is a better invention than some application of it.
Hey, are you Kasper Dik of Sun Microsystems fame?
Nope. I'm Kasper Dupont of usenet fame.
Obviously this attack requires physical access to the machine. And with physical access to the machine there are easier ways to extract keys. So this is really only relevant if you want to protect against somebody with physical access, that wouldn't perform a simpler attack, which could involve disassembling the machine. I think some chipcards you would use to protect keys is a case, where you might worry about such attacks. But how much noise does a chipcard produce, I think with those it would make more sense to meassure the power consumption. Where are the other cases, where you really need to worry about this?
Nope, for it's DSA/DSS all the way, and all the noisy capacitors in the world won't help you break it.
That wouldn't change anything. RSA as well as DSS is based on modulus exponentiation with a secret exponent. If you can get the exponent you have broken the system, it is as simple as that.
Why do I trust it? Because it was developed by the NSA, not a bunch left leaning MIT eggheads.
That kind of logic is useless in the security business. Basing your trust upon who designed the algorithm is stupid. How many (and who) tried to break the algorithm and failed at that is a better meassure on the security. A good rationale behind the design is another good meassure on the security. And finally mathematical proofs.
My point is that you really don't have anything to worry about from 99% of installed programs, and removing them is pointless.
I agree with that. So if we just knew how to identify the last 1%.
The only exception is suid/sgid programs.
/lib/modules when needed. So any package installing object files in /lib/modules could be a security problem, even if they are just drivers for a device you don't have on your system. Another example would be if a package installed something in your PATH, which you might run when you didn't intend to. Imagine if a package installed a /usr/bin/ls file, which you executed when you intended to use /bin/ls.
That is almost what I would have said. But it still is a bit too simplified. Yes, suid/sgid programs can be insecure, but how insecure of course depends on the owner user/group. For example if you install a game, and the executable is sgid to a special game group to get permission to write to a highscore file, I don't consider that particular insecure. Of course there is the theoretical problem that one user might exploit a bug in the game to be able to overwrite the highscore file with some garbage. This is even worse, if he can exploit another bug in the program to take control of the game when it reads a corrupt highscore file, and that way take control of another user's account. But a bug that can be exploited by a corrupt file could exist in any program also if it was not suid/sgid, and it will only affect users who run the program.
Of course suid root executables are always dangerous, and shouldn't be installed unless you need them. But that is not all. A package can potentially be dangerous even if it does not contain suid/sgid executables. For example device inodes with wrong permissions could be a problem. Device inodes should only be installed by the base system, I would stay far away from any other package installing one. Finally there are a few directories in which installing files can be dangerous, because you automatically load files from those directories. I don't know about BSD, but Linux will automatically load drivers from
It would be nice with a tool that could check a package for potentially dangerous things, and tell you if it was perfectly safe to install or if it could potentially be a problem. Still I'm afraid if such a tool was created, people would put too much faith in it and expect it to even warn them about potential trojans, which is an entirely different story.
Why can't people use ISO date format?
I always write the abbreviated month name instead of a number, and I write the year with four digits. That avoids all that confusion. If you want as much confusion as possible write all three with two digits each. Like 060507 or 030102, and nobody will be sure what date I'm thinking about. Seriously a date with month name and four digits in the year is easy to handle in software if you give it just a bit of thought. If users type in years with just two digits (and users should be allowed to do that), immediately convert the year to four digits and show it to the user, and always store it with the full four digits.
Yes, I agree with that. Secret sharing is the way to go if you have some secret you want to be revealed after your death. I have thought about doing something like this, but when I think about it, what secrets do I have that I really want to be revealed? If all of my disk was encrypted I should surely secret share the key. But I only encrypt a few things, and I encrypt those for a reason. For example you wouldn't want anybody to be able to decrypt your GPG signature and forge your electronic signature after you have died. There might be other things you wouldn't want to be revealed even after your death. Of course there might be good reason a few specific informations should be revealed. For example you could write your will on the computer. Then you print one version sign it with a pen, and treat it like any normal person would treat a will. In addition you put an electronic signature on the will, and put it in your encrypted to_be_opened_after_my_death folder. For which you have already secret shared the key. There might be other things to put in that folder like for example a signed message to be published on usenet, and other places where people should know about your death, but are not close enough to you to automatically get to know. Writing a will is a good idea. I haven't done it myself though, but I know to whom I would testament all my digital storage media. It should be someone you trust to use the data in a reasonable way, and who also have the technical competence to do so.
Nothing is totally secure.
You'd need to change the laws of physics to break it. I wish you luck.
A few examples of ads going too far:
- Ads using a significant amount of the bandwidth
- Animations
- Extremely large pictures
- Ads covering parts of the text you want to read
- Popup windows
Some ads have annoyed me enough to actually do something about it. And when I first got started with removing ads, I figured I might as well remove some more of them.I can understand why people discuss how this particular system is implemented. It is not perfectly clear from their explanation. And there are many wrong ways to do it. From their (poor quality) screenshot, it looks like you need to use a webbrowser to login. Not that I understand why they even want people to login, it is a free service, they could just let people use it without any kind of login. Seems it is all done with some kind of javascript, though I'm not absolutely sure that is the case.
It looks like they might think IE is the only application people would ever think about using. In that case they are wrong, if I was ever going to use this system, it would be to run ssh. Will it work only with IE or can any browser be used? Of course IE is required it could be run under wine or VMWare, or you might even reverse engineer the system. Of course once you get it working hiding the ads would be trivial, run the browser under Xvnc for example.
X & video driver didn't install properly (but I fixed it).
That also happened to me when I installed RH6.0 for the first time.
USB scrolling mouse (logitech) didn't install properly (but I fixed it as well).
Interesting with Red Hat Linux 9 and Fedora Core 1 it has worked out of the box under X. But unfortunately it is completely broken under gpm. And by completely broken I mean it was so bad, that it would have been better if it had not worked at all. I have never heard about anybody who got it working.
I couldn't get the sound card to work.
I have tried that as well. My first kernel hack ever was to get ALS120 working under Linux.
I can't remember what it's called. Gentoo?
Yes, Gentoo is one of them. But there are others Source Mage for example. But a bootable self contained system is more than just bzip2 and a compiler. You need, kernel, libraries, a shell, various command line utils, make, binutils, linker, compiler, etc. When it is all there we are talking about multiple MB. Do you really want to have to download nine copies of this when you only need one of them?
Congratulations to whoever made the AYBABTU sign.
Anyone else noticed, that at first the article linked to a picture which wasn't very good. But a short while after the article came on slashdot they swapped around two of the pictures on the server, such that now the link point to a better picture of their sign. DSCF0023.JPG DSCF0033.JPG
so its still interesting to someone like me
You must be new here.
my vpn server uses one TCP port nya nya.
VPN over TCP will give you performance problems. In fact any tunnel device over TCP will give you performance problems. It is the two instances of TCP in the protocol stack that is responsible for most of the problems. Any VPN system built on TCP is broken, it should be build on UDP.
why don't you try OpenVPN?
I don't think it fits my needs. But I really should take a look on it, there might be some useful ideas I can use in my own system.
I'd like to 3DES with SHA3 authentication headers which is generally slow to begin with.
3DES is three times as slow as DES, and it is not three times as secure. While the key size has been increased, it still use the same small 64-bit blocks. For that reason I advice against using the same key for more than 512KB of data. 128 bit AES is probably more secure than 3DES, and AES is as fast as DES.
Granted it's slow as all hell but it does work.
I don't see any reason why it should be slow. You might lose 10% of the bandwidth because of extra headers, but other than that a good implementation should perform just fine. (I admit my own implementation is not yet a good one).
I feel sorry for you if you want to use IPSec
For now I don't. Most of my traffic is ssh anyway. And BTW it is possible to send packets directly between two computers between different NAT boxes. It is tricky, but it can be done. I have written some p2p tunneling software, that does it with UDP packets.
a firewall is essential.
It sure is. The last worm wouldn't have worked without one.
One to take over a running server, and one to elevate to root
In many cases a worm could start spreading without first gaining root priveleges. AFAIR the slapper worm worked like that. But it doesn't do much harm. You can just shut down the vulnurable server and kill the worm process to clean your system. Of course you also have to install the patch before starting the server again.
I see your nat box and raise you a proxy server.
Ha. I have a linux laptop behind a linux iptables NAT box behind another linux iptables NAT box. The NAT boxes are running two different distributions. Beat that if you can.