[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [Open-scap] OVAL and executable stack

Thanx, Peter, I will take a look at your fix.

-----Original Message-----
From: Peter Vrabec [mailto:pvrabec redhat com] 
Sent: Wednesday, July 22, 2009 11:37 AM
To: open-scap-list redhat com; David Niemoller
Subject: Re: [Open-scap] OVAL and executable stack

Hi folks,

this is the patch that fix this issue. I have found 3 types of nested
functions in OVAL code:

1. function that free allocated memory
- these don't make trouble, I haven't touch them. Only one in
oval_behavior.c seemed suspicious to me, so I change it. But these do
not affect stack issue.

2. "consumer" functions that add data(populate) to OVAL model. These
functions don't propagate data to higher context. Easy fix.

3. "consumer" functions that propagate data to higher context. These we
problematic, I don't like the fix so much, but I don't know better
solution for us now.

void oval_value_consume_text(char *string, void *user) {
       char **text = (char **) user;
       *text = string;
oval_value_parse_tag() {
        char *text;
        oval_parser_text_value(reader, context,
                                          (void*) &text); }

David, if you can, take a look at the patch please. I hope I didn't
break anything. It's tested against scap-oval-rhel5.xml. Maybe you can
find better solution then me. thnx.


On Tuesday 07 July 2009 11:37:55 pm Steve Grubb wrote:
> On Tuesday 07 July 2009 05:16:11 pm Pierre Chifflier wrote:
> > Having an executable stack is a really bad idea (for security),
> Yes, I agree. We are in the process of refactoring some of the code 
> for the next release.
> > Generally, this comes from wrong code, for example local functions 
> > in gcc (functions defined inside another functions): gcc places 
> > these function on the stack, and so needs the executable bit.
> >
> > There are some local functions, for ex:
> > src/OVAL/oval_affected.c +88
> > ------------------
> > void oval_affected_free(struct oval_affected *affected) {
> >         void free_string(void *string) {
> >         free(string);
> >         }
> > ------------------
> >
> > (BTW, this code looks seriously wrong. Better define a static 
> > function to do the same ...)
> Agreed.
> > Are there any plans to remove such code ? Would you accept a patch 
> > replacing such calls by static functions ?
> Yes, these should be removed. As for a patch, check against the git 
> repository and see if the problem code is still there. They may have 
> been fixed or another patch may be in work.
> -Steve
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list redhat com
> https://www.redhat.com/mailman/listinfo/open-scap-list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]