10.9 Mavericks is your security update for 10.6 through 10.8.5

Mavericks is free.

Its system requirements are the same as for Mountain Lion

http://www.apple.com/osx/specs/

http://support.apple.com/kb/HT5444

It is also a security update:

http://support.apple.com/kb/HT1222

http://support.apple.com/kb/HT6011

I surmise that Apple does not intend to provide security updates for older OS versions.  At least not for 10.8.

If you want to get patched, start upgrading to 10.9…

Update: 10/4/2013

While it was fun to speculate about Apple forcing us to upgrade to 10.9.  It was just speculation.  I now believe I was wrong and I expect Apple to release updates for older versions similar to its past behavior.

 

Get and use secure supported LDAP SASL authentication mechanisms

You don’t have to use insecure clear text Simple BIND authentication for accessing your LDAP servers.

Get list of supported authentication mechanisms:

ldapsearch -h example.com -x -b "" -s base -LLL supportedSASLMechanisms

Kerberos GSSAPI Example:

kinit
ldapsearch -v -Y GSSAPI -h example.com -b "DC=example,DC=com" "(sAMAccountName=someusername)"

DIGEST-MD5 Example:

ldapsearch -v -Y DIGEST-MD5 -h example.com -U someusername -R example.com -b "DC=example,DC=com"\
 "(sAMAccountName=someusername)"
Note: For Active Directory Digest Authentication to work, you may need to enable Reversible encryption on the account’s password and change the user’s password once.

Inspect Running Mac OS X Applications with F-Script

Objective C is a Dynamic Runtime, so you can load code like plugins during runtime. This dynamic runtime can be very useful for exploring what applications are doing. I use this to assess the security of applications for example.

F-Script provides an easy way to inject itself into a running app and explore around.

Download F-Script here

Launch the app you want to explore.

Then find the process id number of the app in a Terminal shell:

ps auxww | grep “App Name

Load the F-Script Framework into the app and insert its menu using:

sudo gdb --pid AppNameProcessID --batch --nx --command=/dev/stdin << EOT
p (char)[[NSBundle bundleWithPath:@"path/to/Library/Frameworks/FScript.framework"] load]
p (void)[FScriptMenuItem insertInMainMenu]
EOT

I found the above snippet by reviewing this automator service.

Note that sudo is only required if you are not in the _developer group.

At this point, switch to your running application.  You will notice an F-Script Menu is added to the menu bar.

Choose Console from the F-Script menu and type:

del := NSApplication sharedApplication delegate

This will give you a reference to the application delegate.  The application delegate is a top level class of the application, so it should provide a good starting point.

Next, choose Open Object Browser from the F-Script menu.

Now you should have a nice GUI window to explore the app.

Click on del in the Workspace to explore the app delegate.  You can call methods, change values, etc.

See the F-Script documentation for more details.

Enjoy

Shell Injection with AppleScript’s do shell script

AppleScript’s do shell script capability is immensely useful, but if you are sending variable data to do shell script, always validate input and use quoted form of variableName. See the following example:

set dialogResult to (display dialog "Enter a directory name to pass to ls:" default answer ";say boo" buttons {"Cancel", "Quoted Form", "Raw"})

if button returned of dialogResult is "Quoted Form" then
try
set theCommand to "ls ~/" & quoted form of text returned of dialogResult
display dialog "Will execute:" & return & theCommand & return & "Proceed?"
do shell script theCommand
end try
else
try
set theCommand to "ls ~/" & text returned of dialogResult
display dialog "Will execute:" & return & theCommand & return & "Proceed?"
do shell script theCommand
end try
end if

Note you’ll have to fix the quotes to standard double quotes to get this to compile. I couldn’t get wordpress to cooperate.

Unix Environment Variable Scope/Security

I recently encountered a command line tool which exposed passwords in the process listing.

The command would also also accept a password as an environment variable. I was concerned with the security of storing a password in an environment variable.

This article at itworld.com does a nice job explaining environment variable scope.

Environment variables are only accessible in the shell in which they are set.

If you export the variable, it is accessible to any subshell of the shell in which it is exported. Simply logging in as another user on the system or even the same user does not allow access to the exported variable.

So, until someone corrects me, I believe that setting and exporting environment variables containing passwords in a script does protect the password from exposure. As soon as the command requiring the password has completed, the variable can be reset to an empty string to prevent any further access to the password.