Faculty of Engineering and Mathematical Sciences 
Not logged in (login)

help4407


This forum is provided to promote discussion amongst students enrolled in Open Source Tools and Scripting (CITS4407).
 
Options:
RSS cloud
Jump to:

Lecture recording on may 14

6 of 390 articles shown, currently no other people reading this forum.
photo
From: Deepakraj S.
Date: Thu 21st May 2020, 6:54pm
Actions: 
        Login-to-reply

 

Hi,

The lecture recording for May 14 is blank with blue screen. was there no lecture 
recorded on that day . i am bit confused ?

thanks

Lecture recording on may 14

photo
From: Christopher M.
Date: Fri 22nd May 2020, 7:39am
Actions: 
        Login-to-reply

 

"Deepakraj Sugumaran" <22*8*9*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> The lecture recording for May 14 is blank with blue screen. was there no lecture 
> recorded on that day . i am bit confused ?

You're correct;  nor is the lecture of yesterday, yet.
A big weekend coming up, as many staff have been busy this week entering (fighting) the new 
ExamSoft software.

Lecture recording on may 14

photo
From: Lee dB.
Date: Fri 22nd May 2020, 11:58am
Actions: 
        Login-to-reply

 

Interestingly, Examplify uses lots of small shell scripts on Mac to go through and disable services, 
change firewall rules and so forth, then (mostly) reverse the process. From a security perspective, 
it would be interesting to see if the integrity of these files is validated prior to execution, 
especially as I think they run with elevated privileges. I’d assume they would be. 

Lecture recording on may 14

photo
From: Christopher M.
Date: Fri 22nd May 2020, 12:32pm
Actions: 
        Login-to-reply

 

"Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> Interestingly, Examplify uses lots of small shell scripts on Mac to go through and disable services, 
> change firewall rules and so forth, then (mostly) reverse the process. From a security perspective, 
> it would be interesting to see if the integrity of these files is validated prior to execution, 
> especially as I think they run with elevated privileges. I’d assume they would be. 

My early examination of some of it, was that it kept the checksums of those scripts in its binary - but then I 
thought, if it was going down that path, why doesn't it keep the scripts in its binary, and then run them 
dynamically?   Also, would leave less guff behind.

Lecture recording on may 14

photo
From: Lee dB.
Date: Fri 22nd May 2020, 1:46pm
Actions: 
        Login-to-reply

 

"Christopher McDonald" <ch*i*.*c*o*a*[email protected]*a*e*u*a*> wrote:

> "Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:
> 
> > Interestingly, Examplify uses lots of small shell scripts on Mac to go through and disable services, 
> > change firewall rules and so forth, then (mostly) reverse the process. From a security perspective, 
> > it would be interesting to see if the integrity of these files is validated prior to execution, 
> > especially as I think they run with elevated privileges. I’d assume they would be. 
> 
> My early examination of some of it, was that it kept the checksums of those scripts in its binary - but then I 
> thought, if it was going down that path, why doesn't it keep the scripts in its binary, and then run them 
> dynamically?   Also, would leave less guff behind.

Ah, that's interesting. I had wondered if having the shell scripts as standalone files would also more easily permit some type of race condition exploit, where the contents of the files could be changed in between having their contents verified, and being executed?

 From a shell scripting perspective, it also got me thinking about the context these scripts are being run under, and if it could be possible to create aliases to innocuous "dummy" utilities that do nothing (or run with a modified path environment). From memory (I only looked at it briefly), the scripts don't even seem to take particular care to ensure that all commands execute successfully.

Still, it's interesting to see how they're put together in a piece of commercial software.

Lecture recording on may 14

photo
From: Christopher M.
Date: Sun 24th May 2020, 7:34am
Actions: 
        Login-to-reply

 

"Lee de Byl" <10*0*8*[email protected]*u*e*t*u*a*e*u*a*> wrote:

> Ah, that's interesting. I had wondered if having the shell scripts as standalone files would also more easily permit some type of race condition exploit, where the contents of the files could be changed in between having their contents verified, and being executed?

[all other readers can safely ignore this reply]

There's certainly a set of race conditions there, but probably quite difficult to get that 1 in 10000 chance to catch the time window during the reboot sequence.
Another approach could have been to open each script (file), fork new processes, set the trace bit in the children, exec the scripts (which will immediately pause them, giving
control back to the parent), then checksum the scripts before resuming their execution.  Remember that first opening a file means that a process retains access to the original/opened
file, rather than any future changed instance of it.
This Page


Program written by: [email protected]
Feedback welcome
Last modified:  2:34pm Sep 18 2020