Entries Tagged 'Coding' ↓

This is nothing new, and it’s strictly what the POSIX specification warns about mlock() & munlock(). As you may already know, mlock() locks memory to prevent it from being swapped to disk (for example, if you require cryptographic secrets such as encryption keys to be memory resident during system stress, preventing resilience on disk and other media). munlock() does exactly the opposite: it unlocks memory.

The problem is that both functions don’t necessarily work in the same manner across different implementations. The address parameter to both might be required to be page-aligned (rounded up to the size of a memory page, for example 4096 bytes in x86).

What happens if we supply a non-page aligned memory address? If the implementation rounds up by default, we will be either locking a whole page or unlocking it, if we use mlock() or munlock() respectively. That means all the memory contents within the same page will be affected. This might not be an issue during locking, but when you are unlocking, it’s a different situation… we might expose data that was supposed to remain locked and compromise other secrets.

Continue reading →

We’ve been talking to a kernel developer of the NetBSD project (probably the most portable operating system out there), regarding its security status and some potential enhancements.

While reading through the secmodel securelevel source, we spotted this interesting snippet:

case KAUTH_REQ_SYSTEM_TIME_SYSTEM: {

 struct timespec *ts = arg1;
 struct timeval *delta = arg2;

/*
  * Don't allow the time to be set forward so far it will wrap
  * and become negative, thus allowing an attacker to bypass
  * the next check below.  The cutoff is 1 year before rollover
  * occurs, so even if the attacker uses adjtime(2) to move
  * the time past the cutoff, it will take a very long time
  * to get to the wrap point.
  *
  * XXX: we check against INT_MAX since on 64-bit
  *      platforms, sizeof(int) != sizeof(long) and
  *      time_t is 32 bits even when atv.tv_sec is 64 bits.
  */

 if (securelevel > 1 &&
     ((ts->tv_sec > INT_MAX - 365*24*60*60) ||
      (delta->tv_sec < 0 || delta->tv_usec < 0)))
 	result = KAUTH_RESULT_DENY;

break;
}

We’ve been coming across different annoyances in our quest of deploying YUI into one of our main products (a few more articles talking about its development coming soon), the Ruby on Rails content management system behind our almost-ready customer portal and corporate site. The problem comes mainly from the coexistence of our custom CSS and JavaScript code, and the YUI specific style-sheets and library files.

• TabView control is rendering the tabs with an incorrect height: possibly caused by style conflicts, but we have confirmed this is not the case (at least our CSS is consistent and not conflicting with YUI).
• Editor component is unable to adjust its size to a sensible default (in other words: it seems unable to match approximately the old size of the barebones textarea element).
• YUILoader is not liking our layout and failed to expose the YAHOO.widget objects properly. Thus we couldn’t make any real use of it without resorting to Event driven functions and slow transitions (as unpleasing as watching a textarea transform into the Editor UI in “real time” ).

The problems are really bugging us and we have considered moving to fully custom code, even if that means delaying the development of some other features that might be of higher priority. Hopefully we will solve the issues soon and keep YUI in place, since the functionality is really complete.

One of the most important features of our content management system is its usability and careful design. We faced a complicated issue with forms: it’s not that uncommon to use tables for a fluid layout, easy to customize using CSS. The typical table-less solution involves using floating labels to the left, with fixed width, and input fields to the right. We’ve seen designs where a help text could be neatly displayed right next to the input, using tables.

Always perform server-side validation and don’t require JavaScript in forms!

This allows support in possibly every web browser out there, without compatibility issues. The code looks clean too.Another feature that boosts the usability of forms is live data input validation. For security reasons, you should never rely on client-side validation, but it comes as an extremely useful aid for showing the user if there’s anything wrongly formatted that requires fixing, before wasting time submitting the form.

We came across LiveValidation (quite an appropriate name ), a neat Prototype-compatible JavaScript library for automating data validation. It’s free (MIT license, for personal and commercial projects) and compatible with every major browser we’ve tested.

Continue reading →