Properly written C and C++ code can and should trap all exceptions. There is no excuse for untrapped buffer overflows in mature commercial code.
Buffer overflows are programmer errors, not program exceptions that signal some kind of event. They can't be "handled" -- they must be eliminated from the source code.
It is possible... this is usually the symptom of buffer overflow error in the server code. An attacker discovers the hole, takes advantage of the vulnerable buffer to "smash the stack", and dupe the process to execute the shellcode (concise machine code that does whatever an attacker wants) planted in the "specially crafted" mail text.
There are other possibilities but buffer overflows are among the most common ones. I didn't RTFA and neither do I know whether this is one but yes, taking over the server by malicious input *is* possible without social engineering, provided the service code is bad enough to be exploited.
The bad guys probably have ways of getting hold of a lot of MS source code; whereas open source is available to you as well.
Agreed. And also remember, the bad guy don't even need the source code to do bad things to you. Analysing disassembly/coredump/binary patches usually suffices for performing an attack.
In a word, the hackers already know what they know because what is there is already there.
This is one of most annoying things about Linux. It sometimes tries to copy Windows, but instead, does a half-assed job.
Why not just use the WIN+R command? Microsoft created the Run command, and the Windows Key makes the keystroke very easy. It is certainly easier than reaching for Alt+F2.
Even Apple created their launch application using the command+spacebar keystroke.
Why can't this be made standard? Instead of having to add some other unsupported key application just to get that mapping to use the Windows Key. Practically all keyboards have the Windows key standard.
Quit whining. Train yourself with EMACS.;)
Well seriously, I believe you should be given the choice of overriding default keyboard bindings. The details would depend on the WM/library used to handle these stuff.
One obvious difference - an advantage to UAC if you will - is apparent in the case of browsers. If a browser needs to be able to upload and download files, it must have a policy defined for that under SELinux. Hence, a compromised browser can also read/write files from/to those same locations without the users' knowledge or consent. That's not possible with UAC and IE7/Chrome. There is only one way (if UAC is not buggy) to have files transferred, and that's through the broker process. Assuming that process is not buggy (looking at you, Adobe) the user *will* know when a file is being downloaded and saved.
I believe in SELinux you can do something similar via "domain transition". If the rule is set properly a browser can have no read/write rights to the files. When it absolutely needs to do so, it must be done by a "helper" process whose security type is transited into the corresponding type capable of doing the requested operations. There are many ways I can think of to do this. Examples would be the browser sending a request to a local authorization daemon, and let it take care of the rest. The daemon then asks the user for authorization. It continues to process the request and run the "helper" in the transited context only when password and confirmation from the user are given. Well this doesn't sound like an optimal solution (the authorizer daemon becomes a single point of failure just like the Adobe one) but that's quite close to what the Windows UAC can do in a similar scenario. By this made-up example I'm merely stating the possibility of implementing this through SELinux mechanism.
And I may be wrong.. I'm no expert in this area. I just happen to be interested enough to get myself into it a bit.
As I put it in another post (http://it.slashdot.org/comments.pl?sid=1118669&cid=26751749), SELinux is not just a user access control (UAC) system. The NSA didn't build it "to address this" as you said. Instead, they built it to implement a much wider range of ideas e.g. role-based access control and security context/type management.
I'm not familiar with the Windows Vista UAC so I can't make reasonable comparison between it and SELinux. However, if they are designed for different jobs, then we are really comparing apples and oranges.
SELinux is not about account permissions. It is based on security contexts which may or may not involve user accounts. For example, the idea of "root" means nothing in SELinux. A process with uid root can't get out of its confined security context and go rampant just because of its root privilege.
Regarding Windows' filesystem access control, it is similar to POSIX ACLs found in almost all Linux distros. These ACLs define the fine-tuned relationship between users and filesystem objects. However, filesystem access control is only a part (albeit important) of OS security, and I think neither SELinux nor Windows UAC is meant to work only in the realm of filesystem control.
Anyway the above description is based on my vague memory of these stuff and I could be wrong.
Looking at the ridiculous benchmarks like "install time", "mouse clicks", I feel sympathetic with the author, who just wasted huge efforts on such pointless stuff to begin with.
Wake me up when you come up with some Really Useful Information(TM).
Slashdot Mirror
The latter.
Properly written C and C++ code can and should trap all exceptions. There is no excuse for untrapped buffer overflows in mature commercial code.
Buffer overflows are programmer errors, not program exceptions that signal some kind of event. They can't be "handled" -- they must be eliminated from the source code.
It is possible... this is usually the symptom of buffer overflow error in the server code. An attacker discovers the hole, takes advantage of the vulnerable buffer to "smash the stack", and dupe the process to execute the shellcode (concise machine code that does whatever an attacker wants) planted in the "specially crafted" mail text.
There are other possibilities but buffer overflows are among the most common ones. I didn't RTFA and neither do I know whether this is one but yes, taking over the server by malicious input *is* possible without social engineering, provided the service code is bad enough to be exploited.
Back in the good, really old days, one's own work being read out loud was considered an honor.
Dear 2619601604C639867C95D816A5E1A1FA,
Unsurprisingly, it appears that md5("ewg") = 2619601604C639867C95D816A5E1A1FA (as verified by echo -n "ewg" | md5sum ).
You should have used a salt. And a better hash function.
Signed,
5fb72929dc95aa57fb6b30652777b6
aba0299f5548fb3e685e22598d8440
d4ef6fd35e1558beb9fb1533a52dbf
9ecd99b411d36f3bbf737a5db36765
eb67a903
Well done. This permalink should be even better. http://en.wikipedia.org/w/index.php?title=Slashdot&oldid=269993818#Truth
Oblig. UserFriedly strip: http://ars.userfriendly.org/cartoons/?id=20061127
Tlon, Uqbar, Orbis Tertius as well as other Jorge Luis Borges stories.
This is just, umm, fantastic -- in the fantastic sense of the word "fantastic".
And I'm very sorry for the Wikipedia link.
To quote Commander Data: "The Borgs don't evolve. They conquer."
It seems that /baller is a symlink, so the output of "ls" should say "l" (symlink) rather than "b" (block device).
The bad guys probably have ways of getting hold of a lot of MS source code; whereas open source is available to you as well.
Agreed. And also remember, the bad guy don't even need the source code to do bad things to you. Analysing disassembly/coredump/binary patches usually suffices for performing an attack.
In a word, the hackers already know what they know because what is there is already there.
I misread that one as "would cost several billion dollars/euros to build an executable" and thought "what the heck of a compiler they are using!!"
Some are secure and others are not. What is secure now could become insecure later, and vice versa.
Nothing replaces good auditing and vigilance.
xterm needs X, which counts as a third app. Not to say your WM etc.
Gnome-terminal for wimps. Real geek uses the non-X11 terminals and GNU Screen ;)
Alt+F2
This is one of most annoying things about Linux. It sometimes tries to copy Windows, but instead, does a half-assed job.
Why not just use the WIN+R command? Microsoft created the Run command, and the Windows Key makes the keystroke very easy. It is certainly easier than reaching for Alt+F2.
Even Apple created their launch application using the command+spacebar keystroke.
Why can't this be made standard? Instead of having to add some other unsupported key application just to get that mapping to use the Windows Key. Practically all keyboards have the Windows key standard.
Quit whining. Train yourself with EMACS. ;)
Well seriously, I believe you should be given the choice of overriding default keyboard bindings. The details would depend on the WM/library used to handle these stuff.
I guess a really good (or bad) app would attempt "chmod +x" on the program and try again if it had tried previously to fork-exec it unsuccessfully.
One obvious difference - an advantage to UAC if you will - is apparent in the case of browsers. If a browser needs to be able to upload and download files, it must have a policy defined for that under SELinux. Hence, a compromised browser can also read/write files from/to those same locations without the users' knowledge or consent. That's not possible with UAC and IE7/Chrome. There is only one way (if UAC is not buggy) to have files transferred, and that's through the broker process. Assuming that process is not buggy (looking at you, Adobe) the user *will* know when a file is being downloaded and saved.
I believe in SELinux you can do something similar via "domain transition". If the rule is set properly a browser can have no read/write rights to the files. When it absolutely needs to do so, it must be done by a "helper" process whose security type is transited into the corresponding type capable of doing the requested operations. There are many ways I can think of to do this. Examples would be the browser sending a request to a local authorization daemon, and let it take care of the rest. The daemon then asks the user for authorization. It continues to process the request and run the "helper" in the transited context only when password and confirmation from the user are given. Well this doesn't sound like an optimal solution (the authorizer daemon becomes a single point of failure just like the Adobe one) but that's quite close to what the Windows UAC can do in a similar scenario. By this made-up example I'm merely stating the possibility of implementing this through SELinux mechanism.
And I may be wrong.. I'm no expert in this area. I just happen to be interested enough to get myself into it a bit.
As I put it in another post (http://it.slashdot.org/comments.pl?sid=1118669&cid=26751749), SELinux is not just a user access control (UAC) system. The NSA didn't build it "to address this" as you said. Instead, they built it to implement a much wider range of ideas e.g. role-based access control and security context/type management.
I'm not familiar with the Windows Vista UAC so I can't make reasonable comparison between it and SELinux. However, if they are designed for different jobs, then we are really comparing apples and oranges.
SELinux is not about account permissions. It is based on security contexts which may or may not involve user accounts. For example, the idea of "root" means nothing in SELinux. A process with uid root can't get out of its confined security context and go rampant just because of its root privilege.
Regarding Windows' filesystem access control, it is similar to POSIX ACLs found in almost all Linux distros. These ACLs define the fine-tuned relationship between users and filesystem objects. However, filesystem access control is only a part (albeit important) of OS security, and I think neither SELinux nor Windows UAC is meant to work only in the realm of filesystem control.
Anyway the above description is based on my vague memory of these stuff and I could be wrong.
It is indeed surprising AND unsurprising.
The video ends with the two guys discussing "what have we learned today". FTFV:
Looking at the ridiculous benchmarks like "install time", "mouse clicks", I feel sympathetic with the author, who just wasted huge efforts on such pointless stuff to begin with.
Wake me up when you come up with some Really Useful Information(TM).
Ubuntu 9.04 is also a beta.
That's funny... however he was not complaining about viruses. Malaria is cause by small protozoa (single-celled organisms). Viruses don't have cells.
Not the great worms... This snake's size just matches that of a "Little Maker" i.e. small ones producing "Water of Life"...
But it should be "Qapla'"!!