I like having the sender pay the reciever whatever the receiver demands in order to accept the email. The receiver would have costs for unknown addresses (maybe higher costs for large messages), maintain a white list of senders for which no or a reduced charge will be applied and would be able to cancel charges once an email is read, etc. The sender, once knowing the charge for accepting the email, could simply cancel the attempt to send or accept the charges. This would of course require a micropayment infrastructure but would allow for recipients to have a much larger say over what they receive and spend time dealing with.
There should also be much better integration between subscription lists and whitelists, so that when one subscribes to a mailing list, that mailing list address is automatically whitelisted.
GNUCash uses XML and can now and will in the future also store data in an SQL database. While this doesn't meet the definition of a "standard format", it does give access to the structured financial data by a standard means.
I didn't say that it was a particularily good idea.:) The following is just conjecture - I don't really know a lot about this... Since WMF is a basically a script of GDI calls (from what I read), maybe the original intent of the function is for printing, but that it's accessible from WMF because of the nature of WMF. Sounds like a failure to abstract interfaces.:) Remember that this code was in Windows 3.0 - a time when data was trusted by default, and features came WAY before security.
Having read the whole thing, I do think that Steve may be jumping to conclusions a bit too quickly.
I think that we ARE talking about the SETABORTPROC vuln that everyone has been talking about; Steve just finds that the vuln doesn't work quite the same way that he was expecting. It seems that Steve is basing his accusation on the fact that he had to set the length field of the code containing WMF record to 1 (an illegal value) in order to get his code to execute. While this seems odd (and sounds like a "magic value"), there is likely a better explanation. Here's one possibility... The advisory from Secunia at http://secunia.com/advisories/18255/ says that the embedded code executes when any error is detected in parsing the WMF file (not only [or ever?] when canceling printing). Maybe the SETABORTPROC function was originally intended for printing but was overloaded to handle parse error callbacks? Depending on how the parsing code was written, it may treat the invalid length value as such a parsing error, but may have already indexed the the beginning of the code block (since it knows the length of the record header) - it just doesn't know when the code block ends. It can then start executing the code block, even though it is an error in the code block's record that caused the error. I wonder if the code block would execute if the correct length was specified but the NEXT record in the WMF contained a similar error (like an invalid length field).
He may very well be correct that someone has intentionally included this mechanism as a backdoor, but he is being premature in making such claims without first consulting the people who have a lot more experience with this vuln than he does. By the way, MS gives access to their source code to a LOT of outside parties - I'm sure that Steve could have found someone to take a look for him.
I don't mean to make an ad hominem attack (this podcast is actually fairly accurate - just jumps to conclusions), but Steve isn't exactly known for being a respected researcher in the security industry - he's a bit of a poser and sensationalist/alarmist. My gut feel is that Steve is continuing on his sensationalist streak, jumping to conclusions and trying to drum up more excitement. He frequently hypes issues to crazy levels and tries to make himself look like a hero/expert. In fact, he usually offers little insight and often tries to pass off regurgitation (often inaccurate) as original research. Just listen to him in this recording talking about "rolling up his sleeves" and "wrote all my own code", etc. Look up his stuff on nano-probes (http://grc.com/np/np.htm) for some funny stuff. I am a security professional and can tell you that much of his writing is BS and/or hyped/obfuscated wording for technologies and techniques that have been in common usage for years and years before he writes about them. I just can't help but take Steve's claims with a grain of salt.
What you're asking for is a mechanism that describes the evolution and relationships between malware entities. That's a different system that depends on an index/lexicon, such as the CME, to be cost effecive (otherwise you have to map the relationships for each different vendor). This is the first step to making the maintenance of such a mechanism cost effective.
The problem with these centralized naming systems is that they lag behind the real world somewhat. There has to be incentive for the vendors to create CME entries when they create new signatures or identify new varients.
Once you're working you'll realize that getting the job isn't where you stop setting goals. You'll want to do a good job and make insightful decisions. You'll learn that you want to contribute to the field that you're working in, beyond hacking out whatever the business tells you to. You'll want to contribute to society. For these things, the better your understanding of your field and the world, the better you'll do - that's why you're going to university.
Now, you can do all of these things without university, but you've got to be very driven and interested in what you're doing. Interest and ambition to contribute more than just labor is the biggest factor in my experience. Jesus isn't remembered for being a carpenter. Ghandi's not remembered for being a lawyer.
Even when comparing with people in similar jobs in the same company you can find surprising differences. Usually these differences come down to timing and perception - how cash flow was when a person was hired, came up for review, etc or how management perceives the person's value (even if it's the same as everyone else's). Often, even things like whether you're married and have kids affect perception enough to effect significant changes in salary.
Robb, nice one. Fuddruckers was inconsiderate in hotlinking to your content without asking you first. The web developer was irrisponsible in doing so because they put Fuddruckers at risk - associating themselves with content that was beyond their control. By definition, while these behaviors may be harmful, they're not malicious - there was no intent to harm anyone.
What you did was malcious. You've acted to cause a large amount of harm and seem to be proud of it. This kind of escalating retribution is lame. It would have been far better to have communicated with them and educated them that hotlinking is inconsiderate. You've passed up an opportunity for an amicable resolution. You knew that the game was popular at their website - they'd probably have paid you for it if you suggested it. Now Fuddrucker's has suffered damage, fewer people get to enjoy your game (those that would find out about it through their site) and you've burned bridges (prospective employers googling your name before they hire?). What was gained?
Fuddruckers was absolutely doing something impolite and should have been corrected, but I'm disappointed that so many people here are defending the actions of the content owner. Being malicious is never respectable. Grow up and get along.
Try CrossOver Office. It's based on Wine and allows you to run Office (maybe not the most bleeding edge version) on Linux. It works pretty well - I use Word and Excel all the time and Outlook once in a while at work on my Linux box.
They're a big party and the processes to prevent kickbacks, etc aren't there. When the cat's away the mice will play.
The leader of the opposition, Mr Harper is less hardcore moral conservative than Bush but he still freaks a lot of people out with his charter rights violating morality. Here, getting gay marrage through was pretty much a breeze, as stopping it would have required a declaration from parlaiment that they were passing legislation in direct contravention of the charter of rights and freedoms (aka the not withstanding clause). The clause was added to appease some of the other provences that weren't totally happy with the wording of the charter at the time by giving them an out. Using the clause would be akin to Bush banning evolution and forcing bible class and having to announce, "I'm passing this knowing that it violates the constitution - suck it up".
I should clarify that when I said, "not much of an issue", I meant that it's of less concern than the unreach problem. I acknowledge that it is a vulnerability and should be mitigated if cost effective.
First, while source quench is pretty blind, it isn't much of an issue - it's ignored for TCP and I'm not sure that it's used for UDP either (if it is, few important services use UDP over the internet).
Path MTU spoofing is really just a variation of the ICMP Unreach spoof attack (same ICMP type). Unreach packets need to "quote" the header of the packet that couldn't be delivered - including source (random 1024-65535) and target port numbers - this allows the sending host to know what connection is being affected. In order for the attacked host to accept a spoofed unreach, the unreach needs to quote the right source IP/port and target IP/port. Most of the time, the source IP, and target IP/port are known but the source port could be one in a few thousand. It used to be that, on modem connections, sending thousands of unreach packets took a few minutes, but now it can be done in seconds or less. Now you can even guess the source IP (drop all connections from a network to a server). Thus, now, the attack is essentially (if not technically) blind since you don't have to find the right combo - you just send all combos.
Well known problems, mitigation long overdue
on
Examining ICMP Flaws
·
· Score: 4, Informative
Using spoofed unreach packets to drop TCP sessions has been around for a LONG time - it used to be called a "nuke" (before the Windows OOB attack, "WinNuke", became more widely known). I know that I've heard of the quench spoof attack, but hadn't heard of the path MTU attack, yet. Using ICMP redirect messages to arrange MITM attacks was also an old one, but I don't think that most stacks pay attention to redirect any more.
While these kinds of risks have been known for a long time, there hasn't really been much attempt to mitigate them. Fernando seems to be a little green, initially thinking that he discovered new vulnerabilities, but he's doing the right thing in pressuring for methods of mitigation. It's a hard fight against complacency. Some of the ideas are clever, but it'll take a lot of convincing to change something so low level as ICMP. For how simple ICMP is, it has lots of security issues; it has got to be made more complicated very carefully.
Not only that, but this is as designed. If you want to guarantee the integrity of the ESP payload, you've got to turn on integrity guarantees. That's why the option is there. Encryption != guaranteed integrity!
Shame on any vendor which doesn't enable integrity checks on ESP payloads by default. If they make it easy enough to use IPSec without understanding it, they've got a responsibility to use secure defaults or warn the user (loudly) when insecure defaults are used.
There are two (or more) really different kinds of users that Debian serves - desktop/SOHO and production/enterprise users. Desktop users run unstable (or testing if they're conservative) and users needing stability and security over features go for stable. Everyone loves being able to apt-get update; apt-get upgrade. Everyone loves having a huge package archive that's accessible without hunting the web. However, the only people happy with the release cycles and maintenance processes are the users who want to run stable. That's why ubuntu has gotten popular - it's filling the desktop niche a bit more. I think though that ubuntu is too specialized for me to like. Eg, their website says that it's GNOME based, but what if I want to run KDE instead? I also don't like installing much out of the box - I want to pick and choose only what I want; Debian lets me do this. I'd love to see:
- The Ubuntu and Debian folks get together to build an awesome base system framework to build around (eg. kernel-package, hotplug, installer, etc) - Try to make it easier/more popular for developers to package their own stuff and put it in contrib. Make it more like freshmeat but with storage.:) - Debian people can maintain stable and follow their current release concepts, but maybe scale back on the number of packages offered. Do stable users really need games and P2P packages, for example? - Ubuntu project can be to build from and extend Debian Unstable.
I would use Ubuntu if it were Debian with more and more up to date packages. I think it makes sense for Ubuntu to be that, although maybe with a prettier installer (please don't take away my ability to start from clean slate). It makes sense that the Ubuntu project would want to derrive Debian packages as they do now, especially if Debian were to scale a bit back. Debian has, in Unstable, main, contrib, and non-free (repositories" (right word?)). There should be an Ubuntu "repository" as well. Eg, say ubuntu patches xmms to add https mp3 streaming. They would put that new package in the ubuntu repository in Debian unstable. The package would have a higher version number than the package in main and would be tagged as having a derrivation (some unique id number or name - eg "ubuntu-https-stream" [perhaps a convention is needed as for version numbers]). The package versioning mechanism would need to be extended so that once you have installed a package with a derrivation, "apt-get upgrade" will not upgrade to a newer version of the package unless the package includes the derrivation. If you wanted to upgrade any way, there could be a command line switch on apt-get to specify that.
Ubuntu would become a new "repository" in Debian, plus media with a tweaked install process. Upgrading a debian unstable box to ubuntu should be as easy as adding an apt sources line and running apt-get update; apt-get upgrade.
This way ubuntu packages can do what they want, will be compatible with Debian unstable, and Debian people will have an incentive to include changes. Debian can focus on their core and the ubuntu project can pick up the juicy desktop parts of the system. I also really liked the collaborative maintainer idea - that would promote the migration of derrivations from the ubuntu repository into unstable.
Just some ideas... I'm quite happy with Debian and I've never found an out of the box Linux that satisfies me in the flexability domain. Too much or wrong stuff installed by default, too little support for weird configs, etc. I mean, my desktop machine doesn't even have a hard drive in it (boots off of a file server in the basement), and setting that up with Debian was a breeze.
If the company that Daimaou's working on now owns the copyright, they can do what they please. Imagine that I wrote some code and gave it to you licenced under the GPL. Nothing stops me from licensing it to someone else under a different license.
Sorry, it seems like the software install notice may be unreleated to the dialog. Perhaps it's another infection vector. Anyway, the argument that the dialogue does not suggest arbitrary code execution stands. Further, other peoples' comments suggest that Verisigned certs allow arbitrary code to run without a prompt. That's horribly lame and shameful if true.
Sorry for the oversight - this has nothing to do with SSL. The browser is prompting the user, stating that the authenticity of the cert can not be validated and is asking the user whether the applet should be trusted anyway. The user is not being asked whether the applet should be trusted with elevated privilege to install software. In fact, in Firefox certificate trusts and software installation trusts are two seperate configuration spaces. Even if the user read the firefox documentation, they would expect to be prompted explicitly for software installs, independantly from certificate issues. There is no mention of privilege or software installation on that dialogue.
My expectation for an applet with a bad cert trying to install software is to: 1. Prompt for trust of certificate 2. AND prompt for permission to install software
My expectation was that trusting this certificate will: 1. if defined in Firefox's Software Install config, run under configured settings for that particular domain 2. OR prompt for further privilege (to install software)
Users are also so used to ignoring certificate problems for SSL sites that the user will always ignore certificate problems for sites that they do not trust. Users do not care if confidentiality and/or integrity of communications with an untrusted site are compromised as they don't really trust the communication to begin with. Users assume (as they should) that attempts by untrusted sites to do anything which may violate security will be prompted for or denied by default.
The notice that Firefox has stopped the installation of software will be disregarded by the user as the user will believe that the installation has been blocked and can only be unblocked by right clicking on that notice. The dialogue with which the user is interacting will not be assumed to be related to the notice that installation of software was prevented.
If it is the case that trusting the applet by providing a positive response to this dialogue results in the applet running outside of a sandbox, I would argue that the dialogue is misleading and extremely dangerous. In this case the dialogue must be changed to be more clear. The dialogues presented by Firefox (or the JVM?) are completely inadequate and must be fixed. Claming that everything is working fine is rediculous if the guy only accepted the dialogue as shown in the screenshot. The user is not at fault.
Further, assuming that there was no certificate problem (eg if the attacker had a Verisign certificate), would the user have been prompted with anything? I certainly would not expect that anyone with a Verisign certificate has an ability to run applets at elevated privilege without me being prompted by my browser. If browsers/JVM will run all signed applets at an elevated privilege I would consider that a major vulnerability and a completely bone headed design. I don't think that this is the case and expect that the user would have to define the host as being allowed to install software in the Firefox configuration.
W.R.T. the security professional comment... few except for those professionals who have in depth experience with applet security would know to have expectations other than those which I described in this message. One can not be an expert in everything. I would suggest that you meant that anyone who would ignore that kind of warning from a site they did not know, on a box they care much about, is definitely NOT a security professional.
The assumption has previously been that Java applets run in a sandbox and can't 0wn your box. Apparently there's a bug in the JVM (although I havn't seen a specific reference to details) and that assumption has been turned on its head.
Everyone is "blaming the user" about ignoring an SSL warning but even an experienced security person is likely to ignore such a warning. I don't give a shit that someone may be man in the middling or sniffing my applet download - most browsers download and run applets by default with no prompt over plain HTTP. The prompt wasn't related to Java, the prompt was related to an invalid SSL cert.
Not only that, just try to undo a "i += rand()" type of statement... or user input... or a network call. Most network protocols do not support "forget the last three statements and roll back in state".:)
Slashdot Mirror
I like having the sender pay the reciever whatever the receiver demands in order to accept the email. The receiver would have costs for unknown addresses (maybe higher costs for large messages), maintain a white list of senders for which no or a reduced charge will be applied and would be able to cancel charges once an email is read, etc. The sender, once knowing the charge for accepting the email, could simply cancel the attempt to send or accept the charges. This would of course require a micropayment infrastructure but would allow for recipients to have a much larger say over what they receive and spend time dealing with.
There should also be much better integration between subscription lists and whitelists, so that when one subscribes to a mailing list, that mailing list address is automatically whitelisted.
GNUCash uses XML and can now and will in the future also store data in an SQL database. While this doesn't meet the definition of a "standard format", it does give access to the structured financial data by a standard means.
I didn't say that it was a particularily good idea. :) The following is just conjecture - I don't really know a lot about this... Since WMF is a basically a script of GDI calls (from what I read), maybe the original intent of the function is for printing, but that it's accessible from WMF because of the nature of WMF. Sounds like a failure to abstract interfaces. :) Remember that this code was in Windows 3.0 - a time when data was trusted by default, and features came WAY before security.
Having read the whole thing, I do think that Steve may be jumping to conclusions a bit too quickly.
I think that we ARE talking about the SETABORTPROC vuln that everyone has been talking about; Steve just finds that the vuln doesn't work quite the same way that he was expecting. It seems that Steve is basing his accusation on the fact that he had to set the length field of the code containing WMF record to 1 (an illegal value) in order to get his code to execute. While this seems odd (and sounds like a "magic value"), there is likely a better explanation. Here's one possibility... The advisory from Secunia at http://secunia.com/advisories/18255/ says that the embedded code executes when any error is detected in parsing the WMF file (not only [or ever?] when canceling printing). Maybe the SETABORTPROC function was originally intended for printing but was overloaded to handle parse error callbacks? Depending on how the parsing code was written, it may treat the invalid length value as such a parsing error, but may have already indexed the the beginning of the code block (since it knows the length of the record header) - it just doesn't know when the code block ends. It can then start executing the code block, even though it is an error in the code block's record that caused the error. I wonder if the code block would execute if the correct length was specified but the NEXT record in the WMF contained a similar error (like an invalid length field).
He may very well be correct that someone has intentionally included this mechanism as a backdoor, but he is being premature in making such claims without first consulting the people who have a lot more experience with this vuln than he does. By the way, MS gives access to their source code to a LOT of outside parties - I'm sure that Steve could have found someone to take a look for him.
I don't mean to make an ad hominem attack (this podcast is actually fairly accurate - just jumps to conclusions), but Steve isn't exactly known for being a respected researcher in the security industry - he's a bit of a poser and sensationalist/alarmist. My gut feel is that Steve is continuing on his sensationalist streak, jumping to conclusions and trying to drum up more excitement. He frequently hypes issues to crazy levels and tries to make himself look like a hero/expert. In fact, he usually offers little insight and often tries to pass off regurgitation (often inaccurate) as original research. Just listen to him in this recording talking about "rolling up his sleeves" and "wrote all my own code", etc. Look up his stuff on nano-probes (http://grc.com/np/np.htm) for some funny stuff. I am a security professional and can tell you that much of his writing is BS and/or hyped/obfuscated wording for technologies and techniques that have been in common usage for years and years before he writes about them. I just can't help but take Steve's claims with a grain of salt.
Sounds more like trespass.
What you're asking for is a mechanism that describes the evolution and relationships between malware entities. That's a different system that depends on an index/lexicon, such as the CME, to be cost effecive (otherwise you have to map the relationships for each different vendor). This is the first step to making the maintenance of such a mechanism cost effective.
The problem with these centralized naming systems is that they lag behind the real world somewhat. There has to be incentive for the vendors to create CME entries when they create new signatures or identify new varients.
Maybe they know what "husbandry" means.
Dont forget one meta post, one meta-meta post, and a partridge in a pear tree.
Once you're working you'll realize that getting the job isn't where you stop setting goals. You'll want to do a good job and make insightful decisions. You'll learn that you want to contribute to the field that you're working in, beyond hacking out whatever the business tells you to. You'll want to contribute to society. For these things, the better your understanding of your field and the world, the better you'll do - that's why you're going to university.
Now, you can do all of these things without university, but you've got to be very driven and interested in what you're doing. Interest and ambition to contribute more than just labor is the biggest factor in my experience. Jesus isn't remembered for being a carpenter. Ghandi's not remembered for being a lawyer.
Even when comparing with people in similar jobs in the same company you can find surprising differences. Usually these differences come down to timing and perception - how cash flow was when a person was hired, came up for review, etc or how management perceives the person's value (even if it's the same as everyone else's). Often, even things like whether you're married and have kids affect perception enough to effect significant changes in salary.
Because the mountains are really really small compared to the Earth.
Robb, nice one. Fuddruckers was inconsiderate in hotlinking to your content without asking you first. The web developer was irrisponsible in doing so because they put Fuddruckers at risk - associating themselves with content that was beyond their control. By definition, while these behaviors may be harmful, they're not malicious - there was no intent to harm anyone.
What you did was malcious. You've acted to cause a large amount of harm and seem to be proud of it. This kind of escalating retribution is lame. It would have been far better to have communicated with them and educated them that hotlinking is inconsiderate. You've passed up an opportunity for an amicable resolution. You knew that the game was popular at their website - they'd probably have paid you for it if you suggested it. Now Fuddrucker's has suffered damage, fewer people get to enjoy your game (those that would find out about it through their site) and you've burned bridges (prospective employers googling your name before they hire?). What was gained?
Fuddruckers was absolutely doing something impolite and should have been corrected, but I'm disappointed that so many people here are defending the actions of the content owner. Being malicious is never respectable. Grow up and get along.
Try CrossOver Office. It's based on Wine and allows you to run Office (maybe not the most bleeding edge version) on Linux. It works pretty well - I use Word and Excel all the time and Outlook once in a while at work on my Linux box.
It just means liberal with spending.
They're a big party and the processes to prevent kickbacks, etc aren't there. When the cat's away the mice will play.
The leader of the opposition, Mr Harper is less hardcore moral conservative than Bush but he still freaks a lot of people out with his charter rights violating morality. Here, getting gay marrage through was pretty much a breeze, as stopping it would have required a declaration from parlaiment that they were passing legislation in direct contravention of the charter of rights and freedoms (aka the not withstanding clause). The clause was added to appease some of the other provences that weren't totally happy with the wording of the charter at the time by giving them an out. Using the clause would be akin to Bush banning evolution and forcing bible class and having to announce, "I'm passing this knowing that it violates the constitution - suck it up".
I should clarify that when I said, "not much of an issue", I meant that it's of less concern than the unreach problem. I acknowledge that it is a vulnerability and should be mitigated if cost effective.
First, while source quench is pretty blind, it isn't much of an issue - it's ignored for TCP and I'm not sure that it's used for UDP either (if it is, few important services use UDP over the internet).
Path MTU spoofing is really just a variation of the ICMP Unreach spoof attack (same ICMP type). Unreach packets need to "quote" the header of the packet that couldn't be delivered - including source (random 1024-65535) and target port numbers - this allows the sending host to know what connection is being affected. In order for the attacked host to accept a spoofed unreach, the unreach needs to quote the right source IP/port and target IP/port. Most of the time, the source IP, and target IP/port are known but the source port could be one in a few thousand. It used to be that, on modem connections, sending thousands of unreach packets took a few minutes, but now it can be done in seconds or less. Now you can even guess the source IP (drop all connections from a network to a server). Thus, now, the attack is essentially (if not technically) blind since you don't have to find the right combo - you just send all combos.
Using spoofed unreach packets to drop TCP sessions has been around for a LONG time - it used to be called a "nuke" (before the Windows OOB attack, "WinNuke", became more widely known). I know that I've heard of the quench spoof attack, but hadn't heard of the path MTU attack, yet. Using ICMP redirect messages to arrange MITM attacks was also an old one, but I don't think that most stacks pay attention to redirect any more.
i p/browse_thread/thread/439b09e36f4738eb/2eacbab1d4 9e966d?q=icmp+unreach+nuke&rnum=3&hl=en#2eacbab1d4 9e966d e curity/browse_thread/thread/37d9a0a870080133/711f4 cc20af1a450?q=icmp+quench+spoof&rnum=1&hl=en#711f4 cc20af1a450 _ thread/thread/e96bd4e594c808d5/3f66eac2a5aa8665?q= icmp+path+mtu+spoof&rnum=2&hl=en#3f66eac2a5aa8665
Here's a post from 1993, for example:
http://groups.google.ca/group/comp.protocols.tcp-
One from 2000:
http://groups.google.ca/group/sol.lists.freebsd.s
One from 2003:
http://groups.google.ca/group/linux.kernel/browse
While these kinds of risks have been known for a long time, there hasn't really been much attempt to mitigate them. Fernando seems to be a little green, initially thinking that he discovered new vulnerabilities, but he's doing the right thing in pressuring for methods of mitigation. It's a hard fight against complacency. Some of the ideas are clever, but it'll take a lot of convincing to change something so low level as ICMP. For how simple ICMP is, it has lots of security issues; it has got to be made more complicated very carefully.
I agree.
Not only that, but this is as designed. If you want to guarantee the integrity of the ESP payload, you've got to turn on integrity guarantees. That's why the option is there. Encryption != guaranteed integrity!
Shame on any vendor which doesn't enable integrity checks on ESP payloads by default. If they make it easy enough to use IPSec without understanding it, they've got a responsibility to use secure defaults or warn the user (loudly) when insecure defaults are used.
There are two (or more) really different kinds of users that Debian serves - desktop/SOHO and production/enterprise users. Desktop users run unstable (or testing if they're conservative) and users needing stability and security over features go for stable. Everyone loves being able to apt-get update; apt-get upgrade. Everyone loves having a huge package archive that's accessible without hunting the web. However, the only people happy with the release cycles and maintenance processes are the users who want to run stable. That's why ubuntu has gotten popular - it's filling the desktop niche a bit more. I think though that ubuntu is too specialized for me to like. Eg, their website says that it's GNOME based, but what if I want to run KDE instead? I also don't like installing much out of the box - I want to pick and choose only what I want; Debian lets me do this. I'd love to see:
:)
- The Ubuntu and Debian folks get together to build an awesome base system framework to build around (eg. kernel-package, hotplug, installer, etc)
- Try to make it easier/more popular for developers to package their own stuff and put it in contrib. Make it more like freshmeat but with storage.
- Debian people can maintain stable and follow their current release concepts, but maybe scale back on the number of packages offered. Do stable users really need games and P2P packages, for example?
- Ubuntu project can be to build from and extend Debian Unstable.
I would use Ubuntu if it were Debian with more and more up to date packages. I think it makes sense for Ubuntu to be that, although maybe with a prettier installer (please don't take away my ability to start from clean slate). It makes sense that the Ubuntu project would want to derrive Debian packages as they do now, especially if Debian were to scale a bit back. Debian has, in Unstable, main, contrib, and non-free (repositories" (right word?)). There should be an Ubuntu "repository" as well. Eg, say ubuntu patches xmms to add https mp3 streaming. They would put that new package in the ubuntu repository in Debian unstable. The package would have a higher version number than the package in main and would be tagged as having a derrivation (some unique id number or name - eg "ubuntu-https-stream" [perhaps a convention is needed as for version numbers]). The package versioning mechanism would need to be extended so that once you have installed a package with a derrivation, "apt-get upgrade" will not upgrade to a newer version of the package unless the package includes the derrivation. If you wanted to upgrade any way, there could be a command line switch on apt-get to specify that.
Ubuntu would become a new "repository" in Debian, plus media with a tweaked install process. Upgrading a debian unstable box to ubuntu should be as easy as adding an apt sources line and running apt-get update; apt-get upgrade.
This way ubuntu packages can do what they want, will be compatible with Debian unstable, and Debian people will have an incentive to include changes. Debian can focus on their core and the ubuntu project can pick up the juicy desktop parts of the system. I also really liked the collaborative maintainer idea - that would promote the migration of derrivations from the ubuntu repository into unstable.
Just some ideas... I'm quite happy with Debian and I've never found an out of the box Linux that satisfies me in the flexability domain. Too much or wrong stuff installed by default, too little support for weird configs, etc. I mean, my desktop machine doesn't even have a hard drive in it (boots off of a file server in the basement), and setting that up with Debian was a breeze.
Dude, server does not mean everything but the GUI. :) Server means, ideally "only what's needed, tested and kept patched".
If the company that Daimaou's working on now owns the copyright, they can do what they please. Imagine that I wrote some code and gave it to you licenced under the GPL. Nothing stops me from licensing it to someone else under a different license.
Sorry, it seems like the software install notice may be unreleated to the dialog. Perhaps it's another infection vector. Anyway, the argument that the dialogue does not suggest arbitrary code execution stands. Further, other peoples' comments suggest that Verisigned certs allow arbitrary code to run without a prompt. That's horribly lame and shameful if true.
In response to the other responses....
Sorry for the oversight - this has nothing to do with SSL. The browser is prompting the user, stating that the authenticity of the cert can not be validated and is asking the user whether the applet should be trusted anyway. The user is not being asked whether the applet should be trusted with elevated privilege to install software. In fact, in Firefox certificate trusts and software installation trusts are two seperate configuration spaces. Even if the user read the firefox documentation, they would expect to be prompted explicitly for software installs, independantly from certificate issues. There is no mention of privilege or software installation on that dialogue.
My expectation for an applet with a bad cert trying to install software is to:
1. Prompt for trust of certificate
2. AND prompt for permission to install software
My expectation was that trusting this certificate will:
1. if defined in Firefox's Software Install config, run under configured settings for that particular domain
2. OR prompt for further privilege (to install software)
Users are also so used to ignoring certificate problems for SSL sites that the user will always ignore certificate problems for sites that they do not trust. Users do not care if confidentiality and/or integrity of communications with an untrusted site are compromised as they don't really trust the communication to begin with. Users assume (as they should) that attempts by untrusted sites to do anything which may violate security will be prompted for or denied by default.
The notice that Firefox has stopped the installation of software will be disregarded by the user as the user will believe that the installation has been blocked and can only be unblocked by right clicking on that notice. The dialogue with which the user is interacting will not be assumed to be related to the notice that installation of software was prevented.
If it is the case that trusting the applet by providing a positive response to this dialogue results in the applet running outside of a sandbox, I would argue that the dialogue is misleading and extremely dangerous. In this case the dialogue must be changed to be more clear. The dialogues presented by Firefox (or the JVM?) are completely inadequate and must be fixed. Claming that everything is working fine is rediculous if the guy only accepted the dialogue as shown in the screenshot. The user is not at fault.
Further, assuming that there was no certificate problem (eg if the attacker had a Verisign certificate), would the user have been prompted with anything? I certainly would not expect that anyone with a Verisign certificate has an ability to run applets at elevated privilege without me being prompted by my browser. If browsers/JVM will run all signed applets at an elevated privilege I would consider that a major vulnerability and a completely bone headed design. I don't think that this is the case and expect that the user would have to define the host as being allowed to install software in the Firefox configuration.
W.R.T. the security professional comment... few except for those professionals who have in depth experience with applet security would know to have expectations other than those which I described in this message. One can not be an expert in everything. I would suggest that you meant that anyone who would ignore that kind of warning from a site they did not know, on a box they care much about, is definitely NOT a security professional.
The assumption has previously been that Java applets run in a sandbox and can't 0wn your box. Apparently there's a bug in the JVM (although I havn't seen a specific reference to details) and that assumption has been turned on its head.
Everyone is "blaming the user" about ignoring an SSL warning but even an experienced security person is likely to ignore such a warning. I don't give a shit that someone may be man in the middling or sniffing my applet download - most browsers download and run applets by default with no prompt over plain HTTP. The prompt wasn't related to Java, the prompt was related to an invalid SSL cert.
Not only that, just try to undo a "i += rand()" type of statement... or user input... or a network call. Most network protocols do not support "forget the last three statements and roll back in state". :)