Sure, but the list of affected web apps is impressive.
WebLogic, WebSphere, JBoss, Jenkins, OpenNMS
The trouble comes from the fact that it looks like using any part of the Commons libs will pull in this vulnerability and the Apache devs are basically saying "don't allow serialised object to come in from the network." but that seriously hinders the usability of a web app.
And as others have pointed out, if you use a serialized object in the cookies - say a state cookie - the vulnerability can be invoked before the user input is touched.
I don't understand why the OP calls it "Java commons"...
Probably because the path where the web applications keep the jar file is.../WEB-INF/lib/commons-collections-3.2.1.jar. No mention of Apache in that path.
The breakfast cereal experiment was one of them. I remember Adam explaining that they were testing the old wife's tale of the cardboard box being more nutritious than the cereal so they had two sets of mice: one group was fed cereal, the other got the cardboard.
The ones with only cardboard resorted to cannibalism.
Exactly. It's tricky to come up with a code snippet that's simple enough to be posted but still shows the messy parts.
The switch I mentioned above could easily be inside a while loop with a blocking call to poll() which then has to loop through the file descriptors and...
Ah, right. Debuggers. I rarely use them. And when I do it's usually for tracing through a memory dump from a crash.
In the real-time, embedded space there are way too many instances where you can't pause the execution. As an example, I need to debug a network communication issue but I don't control the server side of the network. The only option I have is debug messages and offline stack traces.
Depending on the interviewer you might be okay. Asking questions means you have an open mind about a different way of doing things. For entry level positions, I've found that usually works out better.
Calling a function to clean up allocated memory can lead to some really, really odd things like a pointer to a pointer to a pointer. Yes, I have seen that once and it made sense in that system. The main rule is if you allocate it, you clean it up. With C++ it's simpler to let the constructor-destructor deal with it which makes it nice but that's not an option with C.
Also - and we're getting in to the embedded space with this one - why make a stack frame when a JMP will do? Unless you want to macro out the goto by making it look like a function (don't laugh, I've done this...for a reason) keeping things local is always "better".
A function call - stack frame - generally has the following steps: 1 - Push parameters on the stack (along with certain registers). 2 - Push the return location on the stack 3 - Branch to the new function 4 - Push local variables on the stack (along with some other registers,maybe)
And reverse (pop, return, pop, pop) those values on return.
A goto is one function: JMP.
I'm glossing over a few things like inline but you get the idea.
It's a simplified case. Usually this type of thing comes in handy when allocating dynamic memory blocks. Developers from managed languages don't see the need but it comes in handy in C. Mix dynamic memory in with large switch() statements and the goto cleanup_and_return; style becomes easier to maintain.
For example let's say we have a state machine implementation with 10 cases inside a switch and each one has to clean up some memory before returning.
switch (state) { case 1:
if (!do_something())
free memory;
return FAIL_1; case 2:
if (!do_something_else())
free memory;
return FAIL_2; case 3:... }
It's easier to maintain the clean up at one location a la goto cleanup_and_return; than to make sure that each and every case cleans up the correct memory, especially if the clean up changes at some point.
int return_value; switch (state) { case 1:
if (!do_something())
return_value = FAIL1;
goto cleanup_and_return; case 2:
if (!do_something_else())
return_value = FAIL2;
goto cleanup_and_return; case 3:... } cleanup_and_return: free_memory; return return_value;
Define "small".
I have worked on one particular code base where each function was 10 lines or less which was an absolute horror to work on because it created a mess to drill down through 15 layers of function calls to find out what went wrong.
If the code can't be used/called from anywhere else, it doesn't need to be in its own function!
Slashdot Mirror
Sure, but the list of affected web apps is impressive.
WebLogic, WebSphere, JBoss, Jenkins, OpenNMS
The trouble comes from the fact that it looks like using any part of the Commons libs will pull in this vulnerability and the Apache devs are basically saying "don't allow serialised object to come in from the network." but that seriously hinders the usability of a web app.
And as others have pointed out, if you use a serialized object in the cookies - say a state cookie - the vulnerability can be invoked before the user input is touched.
I don't understand why the OP calls it "Java commons"...
Probably because the path where the web applications keep the jar file is .../WEB-INF/lib/commons-collections-3.2.1.jar. No mention of Apache in that path.
The breakfast cereal experiment was one of them. I remember Adam explaining that they were testing the old wife's tale of the cardboard box being more nutritious than the cereal so they had two sets of mice: one group was fed cereal, the other got the cardboard.
The ones with only cardboard resorted to cannibalism.
They didn't show that one.
Exactly. It's tricky to come up with a code snippet that's simple enough to be posted but still shows the messy parts.
The switch I mentioned above could easily be inside a while loop with a blocking call to poll() which then has to loop through the file descriptors and...
But try posting that code to /. :-)
Ah, right. Debuggers. I rarely use them. And when I do it's usually for tracing through a memory dump from a crash.
In the real-time, embedded space there are way too many instances where you can't pause the execution. As an example, I need to debug a network communication issue but I don't control the server side of the network. The only option I have is debug messages and offline stack traces.
Depending on the interviewer you might be okay. Asking questions means you have an open mind about a different way of doing things. For entry level positions, I've found that usually works out better.
Calling a function to clean up allocated memory can lead to some really, really odd things like a pointer to a pointer to a pointer. Yes, I have seen that once and it made sense in that system. The main rule is if you allocate it, you clean it up. With C++ it's simpler to let the constructor-destructor deal with it which makes it nice but that's not an option with C.
Also - and we're getting in to the embedded space with this one - why make a stack frame when a JMP will do? Unless you want to macro out the goto by making it look like a function (don't laugh, I've done this...for a reason) keeping things local is always "better".
A function call - stack frame - generally has the following steps:
1 - Push parameters on the stack (along with certain registers).
2 - Push the return location on the stack
3 - Branch to the new function
4 - Push local variables on the stack (along with some other registers,maybe)
And reverse (pop, return, pop, pop) those values on return.
A goto is one function: JMP.
I'm glossing over a few things like inline but you get the idea.
...and if you don't understand assembly, you should probably not be coding...
I'm willing to bet the number of programmers that understand assembly is far outnumbered by the ones that don't.
If could be a return in the middle of a conditional inside a loop...No GOTO there!
I once worked with a programmer named Vincent. Every variable was v followed by a number.
int v1;
char *v2;
struct wtf_is_this_thing v3;
struct wtf_is_this_thing *v4;
I had a severe dislike for Vincent.
It's a simplified case. Usually this type of thing comes in handy when allocating dynamic memory blocks. Developers from managed languages don't see the need but it comes in handy in C. Mix dynamic memory in with large switch() statements and the goto cleanup_and_return; style becomes easier to maintain.
For example let's say we have a state machine implementation with 10 cases inside a switch and each one has to clean up some memory before returning.
switch (state) ...
{
case 1:
if (!do_something())
free memory;
return FAIL_1;
case 2:
if (!do_something_else())
free memory;
return FAIL_2;
case 3:
}
It's easier to maintain the clean up at one location a la goto cleanup_and_return; than to make sure that each and every case cleans up the correct memory, especially if the clean up changes at some point.
int return_value; ...
switch (state)
{
case 1:
if (!do_something())
return_value = FAIL1;
goto cleanup_and_return;
case 2:
if (!do_something_else())
return_value = FAIL2;
goto cleanup_and_return;
case 3:
}
cleanup_and_return:
free_memory;
return return_value;
Define "small". I have worked on one particular code base where each function was 10 lines or less which was an absolute horror to work on because it created a mess to drill down through 15 layers of function calls to find out what went wrong. If the code can't be used/called from anywhere else, it doesn't need to be in its own function!
I've been doing contract work on OpenStack for a bit and all I have to say is: FUCK PEP8!