Hmm, I don't know. If the computer is properly locked down you should only be able to use a hardware keylogger (you boot into a secured operating system, I presume).
The swipe reader software can be used to show to the admins that these cards are not safe at all. If I read what they were used for, this is pretty serious. If it was a hardware keylogger I would have agreed. Now we are talking about software, and we don't even know *if* he had hardware access.
"The student almost certainly signed an agreement stating the terms of use for the university network. And he almost certainly broke that agreement. If that's the case, then I don't see how the university's response is wrong."
Oh, fuck that. With that mindset you can be fucked over by each and every institution you enter. That's the same as the idiots who tell you to get a different job each time something bad happens with the one he's holding. Basically both the company and the person will be worse off.
Each and every institution you enter will have such an agreement. Maybe he should have stayed out of school?
Seriously, get 4 GB and use 2 GB for a RAM drive, or is your project > 4 GB after compilation (I hope not)? You save the sources in version control anyway, the class files etc are not important and may be lost when something goes wrong. RAM drive for linux is free, Windows versions cost something like 20$, and RAM is rather cheap nowadays. Run your IDE and libraries and Java Docs from your SSD and watch your computer fly...
You could just stick to Java 2 Standard Edition (the base language and API) and Java 2 Enterprise Edition (the API's for database and web development basically).
For J2SE the choice is easy: just use the latest you can download from java.sun.com. You normally only use other implementations if the have specific benefits for an optimized implementation.
There are many other frameworks from web based designs, but the latest editions of J2EE have heavily borrowed from the most successfull ones. And Sun is, in my opinion, generally pretty good in making understandable, easy to use API's. GlashFish is the reference implementation, just use that for starters. If you are, as you say, a jack of all trades, you will learn other frameworks as needed.
You can use Netbeans (available together with the J2SE distro) or my favorite environment Eclipse for development. You could start with the command line tools with J2SE for discovering the compiler and JVM, but after that you will want to use a good IDE. Java's syntax was specifically created to make good IDE's, you will be largely missing the point if you go without refactoring support, searching for Java elements though projects etc.
Other important things you will want to know about: - JUnit testing framework - Ant building framework (cross platform XML makefiles) - The JavaDoc and JAR tools - Static code checking (e.g. checkstyle)
The most interesting thing to begin to understand when you start is how the classpath and classloaders works, so read into that. Another good hint is to understand how you can code in a secure fashion (use "effective java" for that).
Anyone that has done some downloading from a news server and par2-ing and unzipping at the same time can relate to that 50KB/s. Or copying multiple folders at the same time.
I really really will buy a fast SSD once they become available, and I am thinking about buying one or two of of these new WD velociraptors as well. Current hard drives suck. They are slow, noisy and still a bit unreliable (even though they seem to be *much* better than days of old).
Absolutely, but the GP was not defending him, the white panter was just saying that there were mitigating factors. There is a strong difference between the two. Simply said, context does matter, even in the courts. Fortunately, otherwise you would have to execute the executioner of any sentence:)
Most of the people here are much better than some of the one dimensional anonymous cowards that are running around the place. You seem to be able to think only in a straight line, if it's not a dot.
That said, I'm pretty sure I am responding to a troll, so mod parent down and me too for being stupid:)
Then again, the chances the terminator is still in charge by then are pretty low, maybe he could just make it on his second battery. Or they could send another one back in time.
Your article starts with: "this is what happens" while the actual attack has nothing to do with what you're suggesting. Sorry, but that can not be seen as a "general comment".
"The authors expect these problems to be addressed in future releases of Windows and browser plugins shipped by third parties."
The memory protection schemes discussed here are interesting ways of making sure that there are no escalations when native code exploits are found. The problem is that 1) the initial exploit must already have happened 2) once they are cracked, they are exploitable by any application that uses the same techniques that the authors do.
Personally, I think that plugins should have less influence on browser security. They should simply not be allowed to run in the same address space. This would be more something for the browser manufacturers to solve.
Unless you cannot alter memory addresses on said platforms. But then the binary plugins would not work anymore. An interesting fix is also to run the plugins in their own address space, I think somebody did this for firefox/linux 64 bit to run 32 bit plugins. Flash is really mostly used to diplay graphics and sounds, no need to be able to address the entire firefox memory stack.
Interesting guess, but wrong if you look at the PDF. Good try though, better luck next time:)
Hindsight is a good thing to have, going through all the Slashdot comments and invalidating the guesses (one was guessed right by the way so far, so I'm at 1:2).
Ok, lets go downwards a bit more, see what we'll find.
"Well, if they can really get past "all memory protection safeguards"
It seems they can, but only within a process. So don't go jumping to conclusions here either, especially if you base them on the article posted to slashdot.
Well guessed. Now we have the link to the real article, we can confirm this to be the case. You still need another vulnerability to execute the code though. Having executable code on a well placed position in the process is step one, actually executing it is step two. They use a well known vulnerability to do so.
Yes, but I just skimmed the paper and you seem to be correct in all your assessments, so I guess you were paying attention:)
The biggest problem is of course with the "same memory space" issue of the plugins. This is a really bad flaw in the handling of plugins: plugins should not run in the same memory space of the browser (unless no direct memory addressing can occur, e.g. a browser and plugins written in managed code).
To view all web sites, you are quickly running a real plugin, a quicktime plugin, some plugins to view certain images, the Java VM and of course flash. Any problem with any one of these plugins and your browser vulnerability is out of the window, no matter if automatic updates are on or off.
Interesting read. I don't see how this has much to do with Java though. The only thing the Java applet does it put in a lot of machine code that is marked executable. It then uses this by "changing a return code" something you cannot do in Java in itself. The "scripting languages" seem to be used for this purpose only, after that other vulnerabilities come into play (the ANI vulnerability is used).
If I've read it correctly in the time frame provided here.
I've already send a correction to the authors, the CVE for the ANI vulnerability might be incorrect.
"using a variety of scripting languages, such as Java, ActiveX and even.NET object"
I gave up the credibility of the author just after that sentence. But the topic is of major interest regardless of the stupidity of the author. Slashdot at work, we flame the authors and discuss the topic anywho.
Slashdot Mirror
Hmm, I don't know. If the computer is properly locked down you should only be able to use a hardware keylogger (you boot into a secured operating system, I presume).
The swipe reader software can be used to show to the admins that these cards are not safe at all. If I read what they were used for, this is pretty serious. If it was a hardware keylogger I would have agreed. Now we are talking about software, and we don't even know *if* he had hardware access.
"The student almost certainly signed an agreement stating the terms of use for the university network. And he almost certainly broke that agreement. If that's the case, then I don't see how the university's response is wrong."
Oh, fuck that. With that mindset you can be fucked over by each and every institution you enter. That's the same as the idiots who tell you to get a different job each time something bad happens with the one he's holding. Basically both the company and the person will be worse off.
Each and every institution you enter will have such an agreement. Maybe he should have stayed out of school?
Seriously, get 4 GB and use 2 GB for a RAM drive, or is your project > 4 GB after compilation (I hope not)? You save the sources in version control anyway, the class files etc are not important and may be lost when something goes wrong. RAM drive for linux is free, Windows versions cost something like 20$, and RAM is rather cheap nowadays. Run your IDE and libraries and Java Docs from your SSD and watch your computer fly...
I personally believe the distinction was caused by a bug riddled asteroid that caused volcanic eruptions when it crashed into the earth.
You could just stick to Java 2 Standard Edition (the base language and API) and Java 2 Enterprise Edition (the API's for database and web development basically).
For J2SE the choice is easy: just use the latest you can download from java.sun.com. You normally only use other implementations if the have specific benefits for an optimized implementation.
There are many other frameworks from web based designs, but the latest editions of J2EE have heavily borrowed from the most successfull ones. And Sun is, in my opinion, generally pretty good in making understandable, easy to use API's. GlashFish is the reference implementation, just use that for starters. If you are, as you say, a jack of all trades, you will learn other frameworks as needed.
You can use Netbeans (available together with the J2SE distro) or my favorite environment Eclipse for development. You could start with the command line tools with J2SE for discovering the compiler and JVM, but after that you will want to use a good IDE. Java's syntax was specifically created to make good IDE's, you will be largely missing the point if you go without refactoring support, searching for Java elements though projects etc.
Other important things you will want to know about:
- JUnit testing framework
- Ant building framework (cross platform XML makefiles)
- The JavaDoc and JAR tools
- Static code checking (e.g. checkstyle)
The most interesting thing to begin to understand when you start is how the classpath and classloaders works, so read into that. Another good hint is to understand how you can code in a secure fashion (use "effective java" for that).
Have fun!
So "1" + "1" = "11"? Bead counting? Didn't know that :)
"Why stick with one language when you can use all of them as you see fit?"
Because there are only so many API's that fit into my tiny head.
Anyone that has done some downloading from a news server and par2-ing and unzipping at the same time can relate to that 50KB/s. Or copying multiple folders at the same time.
I really really will buy a fast SSD once they become available, and I am thinking about buying one or two of of these new WD velociraptors as well. Current hard drives suck. They are slow, noisy and still a bit unreliable (even though they seem to be *much* better than days of old).
Absolutely, but the GP was not defending him, the white panter was just saying that there were mitigating factors. There is a strong difference between the two. Simply said, context does matter, even in the courts. Fortunately, otherwise you would have to execute the executioner of any sentence :)
Most of the people here are much better than some of the one dimensional anonymous cowards that are running around the place. You seem to be able to think only in a straight line, if it's not a dot.
That said, I'm pretty sure I am responding to a troll, so mod parent down and me too for being stupid :)
Then again, the chances the terminator is still in charge by then are pretty low, maybe he could just make it on his second battery. Or they could send another one back in time.
Your article starts with: "this is what happens" while the actual attack has nothing to do with what you're suggesting. Sorry, but that can not be seen as a "general comment".
"The authors expect these problems to be addressed in future releases of Windows and browser plugins shipped by third parties."
The memory protection schemes discussed here are interesting ways of making sure that there are no escalations when native code exploits are found. The problem is that 1) the initial exploit must already have happened 2) once they are cracked, they are exploitable by any application that uses the same techniques that the authors do.
Personally, I think that plugins should have less influence on browser security. They should simply not be allowed to run in the same address space. This would be more something for the browser manufacturers to solve.
Not anymore imho, but you've guessed wrong on what the problem really was:
Right guesses: 2
Wrong guesses: 5
This is a slippery slope Slashdot is on.
If the PDF was about this you would be right:
Right guesses: 2
Wrong guesses: 4
Sure thing, but the (now available) PDF has nothing to do with that
Right guesses: 2
Wrong guesses: 3
Still, not bad for Slashdot... Reading on.
Unless you cannot alter memory addresses on said platforms. But then the binary plugins would not work anymore. An interesting fix is also to run the plugins in their own address space, I think somebody did this for firefox/linux 64 bit to run 32 bit plugins. Flash is really mostly used to diplay graphics and sounds, no need to be able to address the entire firefox memory stack.
Interesting guess, but wrong if you look at the PDF. Good try though, better luck next time :)
Hindsight is a good thing to have, going through all the Slashdot comments and invalidating the guesses (one was guessed right by the way so far, so I'm at 1:2).
Ok, lets go downwards a bit more, see what we'll find.
"I'd venture a wild-assed guess"
Your guess is wrong, the real article (the pdf) is about memory protection.
"But there is a (temporary) fix that can be patched into the OS by requiring a signature. Yes, those can be forged."
And then you show that you really don't know what you are talking about. Fortunately your article is modded as interesting, not informative.
It's not even an exploit in itself, so you can really disregard the fix as well.
"Well, if they can really get past "all memory protection safeguards"
It seems they can, but only within a process. So don't go jumping to conclusions here either, especially if you base them on the article posted to slashdot.
Well guessed. Now we have the link to the real article, we can confirm this to be the case. You still need another vulnerability to execute the code though. Having executable code on a well placed position in the process is step one, actually executing it is step two. They use a well known vulnerability to do so.
Oh, ah? And how do you know that the underlying library functions that firefox uses are still safe? Sounds like a disaster waiting to happen to me.
Yes, but I just skimmed the paper and you seem to be correct in all your assessments, so I guess you were paying attention :)
The biggest problem is of course with the "same memory space" issue of the plugins. This is a really bad flaw in the handling of plugins: plugins should not run in the same memory space of the browser (unless no direct memory addressing can occur, e.g. a browser and plugins written in managed code).
To view all web sites, you are quickly running a real plugin, a quicktime plugin, some plugins to view certain images, the Java VM and of course flash. Any problem with any one of these plugins and your browser vulnerability is out of the window, no matter if automatic updates are on or off.
Interesting read. I don't see how this has much to do with Java though. The only thing the Java applet does it put in a lot of machine code that is marked executable. It then uses this by "changing a return code" something you cannot do in Java in itself. The "scripting languages" seem to be used for this purpose only, after that other vulnerabilities come into play (the ANI vulnerability is used).
If I've read it correctly in the time frame provided here.
I've already send a correction to the authors, the CVE for the ANI vulnerability might be incorrect.
"using a variety of scripting languages, such as Java, ActiveX and even .NET object"
I gave up the credibility of the author just after that sentence. But the topic is of major interest regardless of the stupidity of the author. Slashdot at work, we flame the authors and discuss the topic anywho.