Really, really, really smart people 2000 years ago were probibally really, really smarter than most people now.
I often ponder this, i mean often the findings or laws of someone who was incredibly smart seem so elementary and obvious, but you have to wonder if they would have seemed so obvious at the time of their findings. We have to remember that often these are the original finders, those who didn't goto school on the subjects, but rather spent their days sitting and thinking about the subjects. Meaning, often these people were not only _really_ smart, but they were also self-taught, which brings the order of magnitude up even more.
We see far, but thats because we stand on the shoulders of giants.
You'll see port 80 connections to your internal webservers and to external sites... but you shouldn't see port 80 connections to other workstations. That's a flag.
It's very easy to do. You should already know what ports/protocols are in use on your network and what should be connecting on them to what. Start there and investigate any usage you didn't expect to see.
You must work in a very small organization where this can be said to be true, or have never actually worked in a SOC-- in which case your advice sounds logical. Take your network, add several thousand more boxes all under different clusters of administrators, give clusters of the boxes different purposes, and then re-evaluate your statement to see if it can be held to be true.
Really? I tend to make my nop's some variation of 'HIYOUDONTKNOWWHATYOUARETALKINGABOUT' or 'AAAAAAAAAHCERTIFICATIONSMEANNOTHING' or 'ILUBYOUINTERNETS', which depending on the platform are very valid opcodes, care to explain to me how exactly you will catch that?
Additionally, I am not the exception, its just that the security industry is full of people who haven't ever actually done much more than believe whatever metasploit told them, so they just don't know how easy it is to sidestep all of their signature detections.. Especially when it comes to shellcode detection.
(sorry i shouldve previewed;[) const char *whawhat = "//bin/../bin//sh";
push SYSCALLOPCODE jmp esp
for(i = 0; i bsize/2; i+=strlen("HILOOKTHISCANBEANOPTOO"));...
xor?
Etc.
your premise that it can catch just about any stack-smashing attack thats not SSL encapsulated is simply foolish. Snort only catches the people stupid enough to think that they can get away with copy/pasting someone elses shellcode from the 90's.
const char *whawhat = "//bin/../bin//sh";
push SYSCALLOPCODE
jmp esp
for(i = 0; i bsize/2; i+=strlen("HILOOKTHISCANBEANOPTOO"));...
xor?
Etc.
your premise that it can catch just about any stack-smashing attack thats not SSL encapsulated is simply foolish. Snort only catches the people stupid enough to think that they can get away with copy/pasting someone elses shellcode from the 90's.
But seriously, when will the manufacterers realize that this is a losing battle? There is several holes with the self destructing dvd concept that are all legit (i.e. phone call, wife sets kitche on fire, etc) in which case you may/may not be able to pick up where you left off-- I, for one, would not accept this. This holds even more true if it comes laden with DRM. Plus, I don't see how you can really protect the media if it can be read, even if its only once, as that read very well could be a copy. So the purpose is self-defeating, so long as it can be read it can be copied, and if it can't be read, well then its useless.
But my point here is mainly that this entire thing is a losing battle, and the paradigm needs to change to where the corporations accept that it is the year 2005, that technology moved faster than them and now their product has become disposable and they cannot realisitically keep a person from copying the data if they wish, I don't really agree with it, as much as I hate the RIAA/MPAA, I do agree that the people deserve to be paid for their work-- however the simple fact of life is that file sharing/dvd ripping/etc is here to stay, and so as I said their paradigm needs to change to view the content itself as disposable/not the product, like TV for instance, all of these expensive shows and movies, all to sell your attention to an advertiser. So you give your content for little or nothing, and find a way to market something else that makes use of that and just accept that some people will steal your product.
But what is new about this method exactly? From what I read the guardpages are not truly guardpages, but more of a side product of having gaps in the addresses. And whats new about immediately free'ing memory and returning it? Isn't that the way things were originally done until everyone realized just how poor on performance it was?
As far as I know, just about every implementation of malloc uses a variation on this method, except for openbsd now. I know dlmalloc uses bins that are sorted by size.
yes, its slow, thats why most implementation act the way they do. As opposed to actually getting memory from the machine/returning it immediately on free, they tend to coalesce them into bigger chunks and stick them in a cache of sorts, the idea here is to avoid fragmentation (by coalescing them into bigger chunks), and to speed things up some.
With that said, I'd imagine this 'new' method of Theo's is even more slow and is very hurtful to performance.
Ah yes, that wouldn't surprise me-- okay strike that comment from the record;]
The reason most malloc implementations do what they do is in the name of speed, and in fact I seem to remember when I first read about this that this has been Theo's pet project for quite some time and they haven't pushed it because performance was so incredibly bad. Really its a catch-22 situation, and I don't think this will fix it, but I suppose if you value security over speed, then this is right up your alley-- although if you are a person like that, you should probably be auditing the code you run.
At any rate, good call, thanks for the more correct information.
whats the performance hit of immediately free'ing everything instead of sticking the free'd memory into bins? Of having to get the memory from the machine everytime with no caching bins/etc? How many wasted pages of memory are there for so called guard pages?
It's not so much that they are cutting edge, its more that other OS's will sacrifice some security for speed and tell the programmers 'program correctly!'.
or at least thats my take.
working with your premise that NULL = 0, then tell me, if NULL is just a macro that gets replaced after the preprocessor is run, then why can I not say:
int foo = NULL;
?
So there is a difference, and thats all i was trying to state-- although admittedly I did it in a bass akwards manner.
because C doesn't have a boolean type
As stated in another comment, C99 does in fact introduce a boolean type.
No, NULL is not definated as 0 in stdlib.h, but rather (void *)0, unless you have a c++ macro defined, then often its just 0.
At any rate ptr = NULL != 0
Slashdot Mirror
Really, really, really smart people 2000 years ago were probibally really, really smarter than most people now.
I often ponder this, i mean often the findings or laws of someone who was incredibly smart seem so elementary and obvious, but you have to wonder if they would have seemed so obvious at the time of their findings. We have to remember that often these are the original finders, those who didn't goto school on the subjects, but rather spent their days sitting and thinking about the subjects. Meaning, often these people were not only _really_ smart, but they were also self-taught, which brings the order of magnitude up even more.
We see far, but thats because we stand on the shoulders of giants.
Funny enough I just want to a hospital emergency room in capitlist america, covered in blood and in a wheelchair half conscious.
My wait? only about 10 hours.
I guess I work in a different world than you.
You'll see port 80 connections to your internal webservers and to external sites ... but you shouldn't see port 80 connections to other workstations. That's a flag.
It's very easy to do. You should already know what ports/protocols are in use on your network and what should be connecting on them to what. Start there and investigate any usage you didn't expect to see.
You must work in a very small organization where this can be said to be true, or have never actually worked in a SOC-- in which case your advice sounds logical. Take your network, add several thousand more boxes all under different clusters of administrators, give clusters of the boxes different purposes, and then re-evaluate your statement to see if it can be held to be true.
Really? I tend to make my nop's some variation of 'HIYOUDONTKNOWWHATYOUARETALKINGABOUT' or 'AAAAAAAAAHCERTIFICATIONSMEANNOTHING' or 'ILUBYOUINTERNETS', which depending on the platform are very valid opcodes, care to explain to me how exactly you will catch that?
Additionally, I am not the exception, its just that the security industry is full of people who haven't ever actually done much more than believe whatever metasploit told them, so they just don't know how easy it is to sidestep all of their signature detections.. Especially when it comes to shellcode detection.
(sorry i shouldve previewed ;[)
...
const char *whawhat = "//bin/../bin//sh";
push SYSCALLOPCODE
jmp esp
for(i = 0; i bsize/2; i+=strlen("HILOOKTHISCANBEANOPTOO"));
xor?
Etc.
your premise that it can catch just about any stack-smashing attack thats not SSL encapsulated is simply foolish. Snort only catches the people stupid enough to think that they can get away with copy/pasting someone elses shellcode from the 90's.
const char *whawhat = "//bin/../bin//sh"; push SYSCALLOPCODE jmp esp for(i = 0; i bsize/2; i+=strlen("HILOOKTHISCANBEANOPTOO")); ...
xor?
Etc.
your premise that it can catch just about any stack-smashing attack thats not SSL encapsulated is simply foolish. Snort only catches the people stupid enough to think that they can get away with copy/pasting someone elses shellcode from the 90's.
But seriously, when will the manufacterers realize that this is a losing battle? There is several holes with the self destructing dvd concept that are all legit (i.e. phone call, wife sets kitche on fire, etc) in which case you may/may not be able to pick up where you left off-- I, for one, would not accept this. This holds even more true if it comes laden with DRM. Plus, I don't see how you can really protect the media if it can be read, even if its only once, as that read very well could be a copy. So the purpose is self-defeating, so long as it can be read it can be copied, and if it can't be read, well then its useless.
But my point here is mainly that this entire thing is a losing battle, and the paradigm needs to change to where the corporations accept that it is the year 2005, that technology moved faster than them and now their product has become disposable and they cannot realisitically keep a person from copying the data if they wish, I don't really agree with it, as much as I hate the RIAA/MPAA, I do agree that the people deserve to be paid for their work-- however the simple fact of life is that file sharing/dvd ripping/etc is here to stay, and so as I said their paradigm needs to change to view the content itself as disposable/not the product, like TV for instance, all of these expensive shows and movies, all to sell your attention to an advertiser. So you give your content for little or nothing, and find a way to market something else that makes use of that and just accept that some people will steal your product.
The idea of a 'sniper' with an 'AK-47' is somewhat oxymoronic. Thats kinda like talking about a neurosurgeon with a sledgehammer.
But what is new about this method exactly? From what I read the guardpages are not truly guardpages, but more of a side product of having gaps in the addresses. And whats new about immediately free'ing memory and returning it? Isn't that the way things were originally done until everyone realized just how poor on performance it was?
This is kinda MS innovation at play here.
As far as I know, just about every implementation of malloc uses a variation on this method, except for openbsd now. I know dlmalloc uses bins that are sorted by size.
yes, its slow, thats why most implementation act the way they do. As opposed to actually getting memory from the machine/returning it immediately on free, they tend to coalesce them into bigger chunks and stick them in a cache of sorts, the idea here is to avoid fragmentation (by coalescing them into bigger chunks), and to speed things up some.
With that said, I'd imagine this 'new' method of Theo's is even more slow and is very hurtful to performance.
hrm, it ate my around 'the alamo'
remember the alamo LinuxCare?
Didn't they go bankrupt? Seriously, I don't think gentoo is used enough in the business world to support this, but who knows I could be wrong.
Ah yes, that wouldn't surprise me-- okay strike that comment from the record ;]
The reason most malloc implementations do what they do is in the name of speed, and in fact I seem to remember when I first read about this that this has been Theo's pet project for quite some time and they haven't pushed it because performance was so incredibly bad. Really its a catch-22 situation, and I don't think this will fix it, but I suppose if you value security over speed, then this is right up your alley-- although if you are a person like that, you should probably be auditing the code you run.
At any rate, good call, thanks for the more correct information.
whats the performance hit of immediately free'ing everything instead of sticking the free'd memory into bins? Of having to get the memory from the machine everytime with no caching bins/etc? How many wasted pages of memory are there for so called guard pages?
It's not so much that they are cutting edge, its more that other OS's will sacrifice some security for speed and tell the programmers 'program correctly!'.
or at least thats my take.
no, we already have them-- they're walking all over the strip here in vegas. oh wait, i think you meant more genuinly a crab instead of crabby ;]
OH MAN I CANT WAIT FOR THE FUTURE! seriously, cyborg fish people with tentacles and hard drive implants, think about it.
i have no comment other than 'word', very well put.
working with your premise that NULL = 0, then tell me, if NULL is just a macro that gets replaced after the preprocessor is run, then why can I not say: int foo = NULL; ? So there is a difference, and thats all i was trying to state-- although admittedly I did it in a bass akwards manner.
i was basically trying to state that its not _exactly_ 0, thus you cannot say int foo = NULL; I mistated what I was attempting to say.
because C doesn't have a boolean type As stated in another comment, C99 does in fact introduce a boolean type. No, NULL is not definated as 0 in stdlib.h, but rather (void *)0, unless you have a c++ macro defined, then often its just 0. At any rate ptr = NULL != 0
Yes, thats basically what I was saying with my 'not as well defined in C' comment.
to be fair, as of C99, C has boolean types as well.
although its hardly used in C, and not as well defined in C, but thats how afterthoughts typically work.
I can print a line to standard output in less than 16 characters though!
(e.g. null != 0, etc)
In C, NULL != 0 either, its equal to (void *)0, which is different.