You could look at the (assembly) code, watching it parse your packet. Suppose there's some switch on the 'message type' field (or whatever), and one of the branches calls a function that calls unlink on the packet's payload. How could that be a bug?... entirely seperate from the normal operation of the program itself. This would be much harder to identify as malicious code.
What? Another port open? A totally different, (typically) unused branch in the protocol's parser? I'd say those are pretty hard to identify as malicious.
I agree, though: it seems strange to make the deletion method so straightforward.
Seriously. Do you think that spammers sign up for all sorts of mailing lists, on purpose, because they love spam? In the court case, both sides agreed that the calls were unwanted (read the brief!), as did the judge (who was also on the list). So why would we expect them to stay off the list?
For what it's worth, I think Nottingham made the right decision. It would be easy to fix the DNC list to block all unwanted calls (not making a special exception for political or charity groups), and that would probably end the first amendment problems. But things that limit a senator's ability to campaign are going to be a quite a bit less popular...... so who're the hypocrites here?
Perhaps for the same reason that big networks provide backbones: because they can sell the bandwidth to people at either side who want to communicate.
It could maybe work as a peer-to-peer system, in which case you wouldn't need that at all. It could almost certainly work as a network of volunteer-based servers (a la IRC).
Yeah, actually, I think he probably understands the law more than we do. The issue here is not "Is the do-not-call registry a good idea?" but "Is it legal for the FCC to create such a list?" Though I love the DNC list I prefer first and foremost that our government follow the rules that we set up for it. If it's important enough (and I think it is), congress can pass a law giving the FCC the purview to make such a list.
I really enjoy "Super Smash Bros. Melee" and Metroid Prime. But I bought it for the GameBoy Player; all these SNES remakes and updates are exactly what I've been missing ever since "3D" took hold... (I second your recommendation for the Castlevania games, by the way).
> No, it can't enforce the environment variables. Using say LD_PRELOAD, would mean, that I could load my GPG.so from >/tmp/hackersTools/GPG.so or by altering LD_LIBRARY_PATH. Can't stop that if you are not the person doing the comiling and > linking.
Yeah, but so what? I can also take the application binary and mess up its bits. I can change the hard-coded path to the GPG executable so that it executes hacked_gpg. It's only a problem if another user is tricked into running the application with a bogus environment and then types their password into it. But the application has exactly the same problem anyway--once the user types his passphrase into a compromised app, it doesn't matter if it's linked to GPG or communicating over a pipe. Linking with GPG gives you no extra exposure.
Such a library wouldn't need to "override" malloc. It can use its own implementation that allocates pages (through regular malloc) and then locks them before using them. Insisting that the application turn off core dumps and clean up at exit are pretty benign, especially since the application is handling secure data itself (passphrases), so you'd hope that it is equally careful.
> Besides, a buffer overrun, or another flaw in your program could then enable the attacker to read your private key because > it's decoded in your memory space now, not in the seperate GPG space. That's not a huge win, but it's a win.
And your passphrase, passed over IPC to GPG, isn't? That's just as good as having the private key.
I don't see any reason why the issues you list can't be addressed in a library. GPG.so can do its own page locking transparent to the client, it can ignore whatever environment variables it wishes, and it can use mutexes to make it thread safe. It doesn't need to change a default umask (??) when writing to a file that exists, and can simply set the file mode itself when it creat()s the file.
I'm all for OS-enforced abstractions like processes, but I think the issue here is in the design of GPG, not in its basic requirements.
GPG is part of the GNU project, which exists to promote free software.
The GPL is not a means to that end. It is in fact contrary to the project's goal, because it discourages commercial adopters.
If you mean the GNU project, then I think that's just wrong. Encouraging the use of free software in commercial software is *against* the goals of GNU. If you mean the GPG project, well, I think you mistake the reason for its existence.
That might be an argument against a shared library, but not a static one. If you don't have this stuff shared between processes then all the arguments you give don't hold. Also, since most operating systems provide an in-kernel randomless pool, there doesn't seem to be any good reason to share data across different programs that all use the library. That seems to suggest that you could also make a good shared library implementation that consisted only of code, if you care about minimizing the amount of duplicated code in memory.
The GNU project does not exist in order to get people to use their software. It exists in order to promote "free software." To that end, they *do not* want their code inside "commercial" (by that, I mean "proprietary") software, so the BSD license isn't a good choice.
Nobody uses PGP on windows, either. I don't think it has anything to do with licenses, but rather with the fact that it's not automatic to tell if someone (a) has PGP/GPG (b) cares and wants you to use it to send mail.
OTOH, I do agree that "open source" security stuff is pretty crappy.
The 20 second rule on slashdot says that any post you can write in 20 seconds must not be worth posting (unless you reload a few times until the time is up!)
I mean, how would one fix this at a programmatic level, not how do I apply patches that other people have written. Another way of asking would be: how do these patches solve the problem?
Does anyone have any idea how an application (or even resolver) writer could workaround this? All the solutions I've come up with can be defeated by having verisign rotate their IP addresses or domain (sitefinder.verisign.com)...
If you think their servers are going to suffer under a slashdotting if they are now accepting ALL mistyped/obsolete domain names, think again. The slashdot traffic will be totally insignificant.
Man, did you check out their "terms of service"? That shit is hilarious!
" 14. By using the service(s) provided by VeriSign under these Terms of Use, you acknowledge that you have read and agree to be bound by all terms and conditions here in and documents incorporated by reference."
HOW THE FUCK AM I SUPPOSED TO READ AND AGREE TO BE BOUND TO TERMS, when I arrived at the site by mis-typing a domain name????
From the privacy policy:
"Under no circumstances do we collect any personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life."
No? What about when I go to any political site, sex site, health site, religious site, etc, and don't type the domain name correctly?
Slashdot Mirror
how can it be determined
... entirely seperate from the normal operation of the program itself. This would be much harder to identify as malicious code.
You could look at the (assembly) code, watching it parse your packet. Suppose there's some switch on the 'message type' field (or whatever), and one of the branches calls a function that calls unlink on the packet's payload. How could that be a bug?
What? Another port open? A totally different, (typically) unused branch in the protocol's parser? I'd say those are pretty hard to identify as malicious.
I agree, though: it seems strange to make the deletion method so straightforward.
If you're interested in making NES music (the Game Boy is more powerful, actually, but I personally feel more nostalgia for the NES), check out MCK:
http://www.geocities.co.jp/Playtown-Denei/9628/ma
You can even use my MIDI converter MIDIMML so that you aren't stuck typing numbers into a text-based sequencer.
Also, my Tom 7 Entertainment System project has a bunch of original NES-ish songs for you.
Seriously. Do you think that spammers sign up for all sorts of mailing lists, on purpose, because they love spam? In the court case, both sides agreed that the calls were unwanted (read the brief!), as did the judge (who was also on the list). So why would we expect them to stay off the list?
For what it's worth, I think Nottingham made the right decision. It would be easy to fix the DNC list to block all unwanted calls (not making a special exception for political or charity groups), and that would probably end the first amendment problems. But things that limit a senator's ability to campaign are going to be a quite a bit less popular...... so who're the hypocrites here?
Why don't we just infect the books with rabies-induced hydrophobia in the first place?
So true. I was about to post this exact situation!
Perhaps for the same reason that big networks provide backbones: because they can sell the bandwidth to people at either side who want to communicate.
It could maybe work as a peer-to-peer system, in which case you wouldn't need that at all. It could almost certainly work as a network of volunteer-based servers (a la IRC).
> Who gives us the right to use their servers though?
Nobody. That's why we shouldn't use non-open networks.
Nice, but I really want a solid-state device so that it uses less battery power and is resistant to dropping. Does anybody know one? 128mb is plenty.
Did he have that N64 upgrade thing? There was a small unit that came with several games and upgraded the video, or something, I don't remember.
Yeah, actually, I think he probably understands the law more than we do.
The issue here is not "Is the do-not-call registry a good idea?" but "Is it legal for the FCC to create such a list?" Though I love the DNC list I prefer first and foremost that our government follow the rules that we set up for it. If it's important enough (and I think it is), congress can pass a law giving the FCC the purview to make such a list.
I really enjoy "Super Smash Bros. Melee" and Metroid Prime. But I bought it for the GameBoy Player; all these SNES remakes and updates are exactly what I've been missing ever since "3D" took hold... (I second your recommendation for the Castlevania games, by the way).
Delayed so that they could add in real time shadows after seeing the Doom III tech demo.
Wow, Allegro lives? I used to use that back in the mid-nineties for DOS games.
If it now finally works under windows and other platforms, I'd definitely recommend it.
SDL is great, too. It really is very easy to use (for 2D, at least) and quite portable.
> No, it can't enforce the environment variables. Using say LD_PRELOAD, would mean, that I could load my GPG.so from /tmp/hackersTools/GPG.so or by altering LD_LIBRARY_PATH. Can't stop that if you are not the person doing the comiling and
>
> linking.
Yeah, but so what? I can also take the application binary and mess up its bits. I can change the hard-coded path to the GPG executable so that it executes hacked_gpg. It's only a problem if another user is tricked into running the application with a bogus environment and then types their password into it. But the application has exactly the same problem anyway--once the user types his passphrase into a compromised app, it doesn't matter if it's linked to GPG or communicating over a pipe. Linking with GPG gives you no extra exposure.
Such a library wouldn't need to "override" malloc. It can use its own implementation that allocates pages (through regular malloc) and then locks them before using them. Insisting that the application turn off core dumps and clean up at exit are pretty benign, especially since the application is handling secure data itself (passphrases), so you'd hope that it is equally careful.
> Besides, a buffer overrun, or another flaw in your program could then enable the attacker to read your private key because
> it's decoded in your memory space now, not in the seperate GPG space. That's not a huge win, but it's a win.
And your passphrase, passed over IPC to GPG, isn't? That's just as good as having the private key.
I don't see any reason why the issues you list can't be addressed in a library. GPG.so can do its own page locking transparent to the client, it can ignore whatever environment variables it wishes, and it can use mutexes to make it thread safe. It doesn't need to change a default umask (??) when writing to a file that exists, and can simply set the file mode itself when it creat()s the file.
I'm all for OS-enforced abstractions like processes, but I think the issue here is in the design of GPG, not in its basic requirements.
GPG is part of the GNU project, which exists to promote free software.
The GPL is not a means to that end. It is in fact contrary to the project's goal, because it discourages commercial adopters.
If you mean the GNU project, then I think that's just wrong. Encouraging the use of free software in commercial software is *against* the goals of GNU. If you mean the GPG project, well, I think you mistake the reason for its existence.
That might be an argument against a shared library, but not a static one. If you don't have this stuff shared between processes then all the arguments you give don't hold. Also, since most operating systems provide an in-kernel randomless pool, there doesn't seem to be any good reason to share data across different programs that all use the library. That seems to suggest that you could also make a good shared library implementation that consisted only of code, if you care about minimizing the amount of duplicated code in memory.
The GNU project does not exist in order to get people to use their software. It exists in order to promote "free software." To that end, they *do not* want their code inside "commercial" (by that, I mean "proprietary") software, so the BSD license isn't a good choice.
Nobody uses PGP on windows, either. I don't think it has anything to do with licenses, but rather with the fact that it's not automatic to tell if someone (a) has PGP/GPG (b) cares and wants you to use it to send mail.
OTOH, I do agree that "open source" security stuff is pretty crappy.
The 20 second rule on slashdot says that any post you can write in 20 seconds must not be worth posting (unless you reload a few times until the time is up!)
The "correct" place is just the place you prefer, or are used to.
i don't believe i said that.
You said it in this post.
i also don't believe there's a point to this conversation.
Well, I didn't mean for it to be a flamewar, but, ok.
I mean, how would one fix this at a programmatic level, not how do I apply patches that other people have written. Another way of asking would be: how do these patches solve the problem?
Does anyone have any idea how an application (or even resolver) writer could workaround this?
All the solutions I've come up with can be defeated by having verisign rotate their IP addresses or domain (sitefinder.verisign.com)
What is BIND doing?
If you think their servers are going to suffer under a slashdotting if they are now accepting ALL mistyped/obsolete domain names, think again. The slashdot traffic will be totally insignificant.
Well, this is finally working for me now!
Man, did you check out their "terms of service"? That shit is hilarious!
" 14. By using the service(s) provided by VeriSign under these Terms of Use, you acknowledge that you have read and agree to be bound by all terms and conditions here in and documents incorporated by reference."
HOW THE FUCK AM I SUPPOSED TO READ AND AGREE TO BE BOUND TO TERMS, when I arrived at the site by mis-typing a domain name????
From the privacy policy:
"Under no circumstances do we collect any personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, or sex life."
No? What about when I go to any political site, sex site, health site, religious site, etc, and don't type the domain name correctly?
http://www.sitefinderreallyreallysucks.com/