gmane.linux.redhat.fedora.security

Breakpoint 2012 Call For Papers

2012-05-10T11:48:16

. ______________________________________
._\\. Breakpoint 2012 (___.
: Intercontinental Rialto :
: Melbourne, Australia :
: October 17th-18th :
:__ . ___:
)____________________________________\\
.
www.ruxconbreakpoint.com
www.twitter.com/ruxconbpx

Introduction
------------

Breakpoint is a new security conference to be held on the 17th and 18th of
October, in Melbourne Australia. The event will show case the work of expert
security researchers from around the world on a wide range of topics.
Breakpoint is organised by the Ruxcon conference team and will offer a
specialised and more professional security conference to complement and lead
into the larger and more casual Ruxcon weekend conference. Breakpoint will
cater towards security researchers and industry professionals alike, with a
focus on cutting edge security research.

With just one day separating both conferences, Breakpoint presents a great
opportunity for our selected speakers to receive a complimentary trip to
Australia and experience both the Breakpoint and Ruxcon conferences, not to
mention the great weather, awesome parties, and friendly people.

Melbourne is Australia's cultural capital, with Victorian-era architecture,
extensive shopping, museums, galleries, theatres, and large parks and gardens.
It is a city of many subcultures, personalities and styles, and it is these
layers that make it so interesting. Melbourne has a vibrant arts and music
scene, eccentric cafes, cobbled lane-ways, quirky shops, intimate bars and
restaurants, and is known as one of the world's great streetart capitals.

Important Dates
---------------

* May 10 Call For Presentations Open
* July 30 Call For Presentations Close
* October 15-16 BreakPoint Training
* October 17-18 BreakPoint Conference
* October 20-21 Ruxcon Conference

Topic Scope
-----------

Topics of interest include, but are not limited to:

o Mobile Device Security
o Exploitation Techniques
o Reverse Engineering
o Vulnerability Discovery
o Rootkit Development
o Malware Analysis
o Code Analysis
o Virtualization, Hypervisor Security
o Cloud Security
o Embedded Device Security
o Hardware Security
o Telecommunications Security
o Wireless Network Security
o Web Application Security
o Law Enforcement Activities
o Forensics
o Threat Intelligence
o You get the idea

Submission Guidelines
---------------------

In order for us to process your submission we will require the following
information:

1. Presentation title
2. Detailed summary of your presentation material
3. Name/Nickname
4. Mobile phone number
5. Brief personal biography
6. Description of any demonstrations involved in the presentation
7. Information on where the presentation material has or will be presented
before Breakpoint

* Preference will be given to presentations that contain original research
that will be first presented at Breakpoint.
* As a general guideline, BreakPoint presentations are between
45 and 60 minutes, including question time.

If you have any enquiries about submissions, or would like to make a
submission, please send an email to bpx-yJMC+TwIlFBgg+z3Qi7H4VaTQe2KTcn/< at >public.gmane.org

Speaker Benefits
----------------

Speakers at BreakPoint will be entitled to the following benefits:

- A round trip economy airfare to Melbourne (total cost limit applies)
- Three nights accommodation at the Intercontinental Rialto
- Complementary registration for Breakpoint and Ruxcon conferences
- Invitation to all BreakPoint and Ruxcon parties
- Unlock 'Presented on world's smallest continent' achievement

* All speaker benefits apply to a single speaker per submission.

Contact
-------

If you have any questions or queries, contact us at:

* Email: bpx-yJMC+TwIlFBgg+z3Qi7H4VaTQe2KTcn/< at >public.gmane.org
* Twitter < at >ruxconbpx
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Ruxcon 2012 Call For Papers

2012-04-19T05:04:06

Ruxcon 2012 Call For Papers

The Ruxcon team is pleased to announce the call for papers for the 2012 annual Ruxcon conference.

This year the conference will take place over the weekend of 20th and 21st of October at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of July.

* What is Ruxcon?

Ruxcon is the premier technical computer security conference in the Australia. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information, please visit http://www.ruxcon.org.au

* Presentation Information

Presentations are set to run for 40 to 50 minutes, and will be of a formal nature, with slides and a speech.

* Topics

Topics of interest include, but are not limited to:

o Mobile Device Security
o Virtualization, Hypervisor, and Cloud Security
o Malware Analysis
o Reverse Engineering
o Exploitation Techniques
o Rootkit Development
o Code Analysis
o Forensics and Anti-Forensics
o Embedded Device Security
o Web Application Security
o Network Traffic Analysis
o Wireless Network Security
o Cryptography and Cryptanalysis
o Social Engineering
o Law Enforcement Activities
o Telecommunications Security (SS7, 3G/4G, GSM, VOIP, etc)

* Submissions

Submissions should thoroughly outline your desired presentation subject.

If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations< at >ruxcon.org.au

The deadline for submissions is the 15th of July.

If approved we will additionally require:

i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).

* Contacts

Email: presentations< at >ruxcon.org.au
Twitter: ruxcon
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Mu Dynamics, Inc. Security Advisories MU-201202-01 and MU-201202-02for GnuTLS and Libtasn1

Security — 2012-03-21T02:14:00

Hello Open Source Distributors,

Any libgnutls and libtasn1 packages you may have in your environments should be updated to the latest versions in order to correct the below vulnerabilities we released today. Various popular packages such as Wireshark / tshark use these packages and could also be affected.

http://www.gnu.org/software/gnutls/security.html
http://blog.mudynamics.com/2012/03/20/gnutls-and-libtasn1-vulns/

Regards,
Matthew Hall
Mu Dynamics Research Team
Mu Dynamics, Inc.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mu Dynamics, Inc. Security Advisories MU-201202-01 and MU-201202-02 for GnuTLS and Libtasn1

TLS record handling vulnerability in GnuTLS [MU-201202-01]
ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02]

20 March 2012

http://blog.mudynamics.com/2012/03/20/gnutls-and-libtasn1-vulns/
http://labs.mudynamics.com/advisories.html

Affected Products/Versions:

* libgnutls up to 3.0.16.
* libtasn1 up to 2.11.

Product Overview:

GnuTLS is an open source implementation of SSL, TLS and DTLS, with APIs for
encrypted network communications, along with X.509, PKCS #12, OpenPGP, and
other security data types.

Analysis:

Details for TLS record handling vulnerability in GnuTLS [MU-201202-01]:

The block cipher decryption logic in GnuTLS assumed that a record containing
any data which was a multiple of the block size was valid for further
decryption processing, leading to a heap corruption vulnerability.

The bug can be reproduced in GnuTLS 3.0.14 by creating a corrupt
GenericBlockCipher struct with a valid IV, while everything else is stripped
off the end, while the handshake message length retains its original value:

struct {
    opaque IV[SecurityParameters.record_iv_length];
    // corrupt: below items not sent
    /*
    block-ciphered struct {
        opaque content[TLSCompressed.length];
        opaque MAC[SecurityParameters.mac_length];
        uint8 padding[GenericBlockCipher.padding_length];
        uint8 padding_length;
    };
    */
} GenericBlockCipher;

This will cause a segmentation fault, when the ciphertext_to_compressed
function tries to give decrypted data to _gnutls_auth_cipher_add_auth for HMAC
verification, even though the data length is invalid, and it should have
returned GNUTLS_E_DECRYPTION_FAILED or GNUTLS_E_UNEXPECTED_PACKET_LENGTH
instead, before _gnutls_auth_cipher_add_auth was called.

Since the error was not returned soon enough, all of the various operations
ciphertext_to_compressed performs: i.e. setting the IV, removing the padding,
setting the "true" data length with the padding stripped, checking the padding
size and padding payload and verifying HMAC could all reference undefined,
unallocated, or uninitialized memory.

There could be similar ways to reproduce this for AEAD ciphers due to the
various flows through this code, but we did not attempt to do this, and see it
as a topic for further investigation.

Below we trace the execution of the ciphertext_to_compressed function from
lib/gnutls_cipher.c. The unsafe operations and missed opportunities to return
before the heap corruption happens are marked with "***** ... *****" :

 433    static int
 434    ciphertext_to_compressed (gnutls_session_t session,
 435                              gnutls_datum_t *ciphertext,
 436                              uint8_t * compress_data,
 437                              int compress_size,
 438                              uint8_t type, record_parameters_st * params,
 439                              uint64* sequence)
 440    {
...
 511        case CIPHER_BLOCK:
 512          if (ciphertext->size < MAX(blocksize, tag_size) || (ciphertext->size % blocksize != 0)) ***** UNSAFE *****
 513            return gnutls_assert_val(GNUTLS_E_UNEXPECTED_PACKET_LENGTH);
 514
 515          /* ignore the IV in TLS 1.1+
 516           */
 517          if (explicit_iv)
 518            {
 519              _gnutls_auth_cipher_setiv(&params->read.cipher_state,
 520                ciphertext->data, blocksize);
 521
 522              ciphertext->size -= blocksize;
 523              ciphertext->data += blocksize;
 524
 525              if (ciphertext->size == 0) ***** UNSAFE *****
 526                {
 527                  gnutls_assert ();
 528                  return GNUTLS_E_DECRYPTION_FAILED;
 529                }
 530            }
...
 537          if ((ret =
 538               _gnutls_cipher_decrypt (&params->read.cipher_state.cipher,
 539                 ciphertext->data, ciphertext->size)) < 0)
 540            return gnutls_assert_val(ret);
 541
 542          pad = ciphertext->data[ciphertext->size - 1] + 1;   /* pad */
 543
 544          if ((int) pad > (int) ciphertext->size - tag_size)
 545            {
 546              gnutls_assert ();
 547              _gnutls_record_log
 548                ("REC[%p]: Short record length %d > %d - %d (under attack?)\n",
 549                 session, pad, ciphertext->size, tag_size); ***** Message Appears During The Attack *****
 550              /* We do not fail here. We check below for the
 551               * the pad_failed. If zero means success.
 552               */
 553              pad_failed = GNUTLS_E_DECRYPTION_FAILED; ***** Execution Continues Anyway *****
 554              pad %= blocksize;
 555            }
 556
 557          length = ciphertext->size - tag_size - pad;
 558
 559          /* Check the padding bytes (TLS 1.x) */
...
 577          /* Pass the type, version, length and compressed through
 578           * MAC.
 579           */
 580          preamble_size =
 581            make_preamble (UINT64DATA(*sequence), type,
 582                           length, ver, preamble);
 583          ret = _gnutls_auth_cipher_add_auth (&params->read.cipher_state, preamble, preamble_size);
 584          if (ret < 0)
 585            return gnutls_assert_val(ret);
 586
 587          ret = _gnutls_auth_cipher_add_auth (&params->read.cipher_state, ciphertext->data, length); ***** UNSAFE, crashes here *****
 588          if (ret < 0)
 589            return gnutls_assert_val(ret); ***** Crashes Before Error Is Returned *****
...

The segmentation fault appears as follows in GDB:

Program received signal SIGSEGV, Segmentation fault.
0x003b9946 in _nettle_sha256_compress (state=0x807f128,
    input=0x808f000 <Address 0x808f000 out of bounds>, k=0x3cdb60)
    at sha256-compress.c:111
111     sha256-compress.c: No such file or directory.
        in sha256-compress.c
(gdb) bt
#0  0x003b9946 in _nettle_sha256_compress (state=0x807f128,
    input=0x808f000 <Address 0x808f000 out of bounds>, k=0x3cdb60)
    at sha256-compress.c:111
#1  0x003b961b in nettle_sha256_update (ctx=0x807f128, length=4294916861,
    data=0x808effc "") at sha256.c:92
#2  0x003b336d in nettle_hmac_sha256_update (ctx=0x807f050, length=4294967280,
    data=0x8082b09 '\017' <repeats 16 times>) at hmac-sha256.c:43
#3  0x0021a749 in wrap_nettle_hmac_update (_ctx=0x807f050, text=0x8082b09,
    textsize=4294967280) at mac.c:231
#4  0x00158233 in _gnutls_hmac (handle=0x807ef9c, text=0x8082b09,
    textlen=4294967280) at ./gnutls_hash_int.h:73
#5  0x00158b35 in _gnutls_auth_cipher_add_auth (handle=0x807ef78,
    text=0x8082b09, textlen=-16) at gnutls_cipher_int.c:190
#6  0x001473de in ciphertext_to_compressed (session=0x807d810,
    ciphertext=0xbfffe8a4, compress_data=0x8083da4 "", compress_size=16384,
    type=22 '\026', params=0x807ed48, sequence=0x807efcc)
    at gnutls_cipher.c:587
#7  0x00145cdc in _gnutls_decrypt (session=0x807d810,
    ciphertext=0x8082af9 "\252\257C/7\301\362\352h|d\275#\312\027\312", '\017' <repeats 16 times>, ciphertext_size=32, data=0x8083da4 "", max_data_size=16384,
    type=GNUTLS_HANDSHAKE, params=0x807ed48, sequence=0x807efcc)
    at gnutls_cipher.c:159
...
(gdb)

The segmentation fault appears as follows in Valgrind Memcheck:

==29586== Invalid read of size 1
==29586==    at 0x40274B9: memcpy (mc_replace_strmem.c:497)
==29586==    by 0x42BC5A6: nettle_sha256_update (sha256.c:92)
==29586==    by 0x42B636C: nettle_hmac_sha256_update (hmac-sha256.c:43)
==29586==    by 0x411C748: wrap_nettle_hmac_update (mac.c:231)
==29586==    by 0x405A232: _gnutls_hmac (gnutls_hash_int.h:73)
==29586==    by 0x405AB34: _gnutls_auth_cipher_add_auth (gnutls_cipher_int.c:190)
==29586==    by 0x40493DD: ciphertext_to_compressed (gnutls_cipher.c:587)
==29586==    by 0x4047CDB: _gnutls_decrypt (gnutls_cipher.c:159)
...
==29586==  Address 0x4464411 is 0 bytes after a block of size 89 alloc'd
==29586==    at 0x4024F12: calloc (vg_replace_malloc.c:467)
==29586==    by 0x4049AE4: _mbuffer_alloc (gnutls_mbuffers.c:288)
==29586==    by 0x4049C49: _mbuffer_linearize (gnutls_mbuffers.c:349)
==29586==    by 0x40462FB: _gnutls_recv_in_buffers (gnutls_record.c:996)
==29586==    by 0x404D01C: _gnutls_handshake_io_recv_int (gnutls_buffers.c:1174)
==29586==    by 0x4050383: _gnutls_recv_handshake (gnutls_handshake.c:1260)
...
==29586== Invalid read of size 1
...
==29586==  Address 0x4464412 is 1 bytes after a block of size 89 alloc'd
...
==29586== Process terminating with default action of signal 11 (SIGSEGV)
==29586==  Access not within mapped region at address 0x4779000
==29586==    at 0x42BC946: _nettle_sha256_compress (sha256-compress.c:111)
==29586==    by 0x42BC61A: nettle_sha256_update (sha256.c:92)
==29586==    by 0x42B636C: nettle_hmac_sha256_update (hmac-sha256.c:43)
==29586==    by 0x411C748: wrap_nettle_hmac_update (mac.c:231)
==29586==    by 0x405A232: _gnutls_hmac (gnutls_hash_int.h:73)
==29586==    by 0x405AB34: _gnutls_auth_cipher_add_auth (gnutls_cipher_int.c:190)
==29586==    by 0x40493DD: ciphertext_to_compressed (gnutls_cipher.c:587)
...
Segmentation fault

Details for ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02]:

Various functions using the ASN.1 length decoding logic in Libtasn1 were
incorrectly assuming that the return value from asn1_get_length_der is always
less than the length of the enclosing ASN.1 structure, which is only true for
valid structures and not for intentionally corrupt or otherwise buggy
structures.

Here is an example of unsafe asn1_get_length_der usage from
lib/minitasn1/decoding.c, in the asn1_der_decoding function:

0812    asn1_retCode
0813    asn1_der_decoding (ASN1_TYPE * element, const void *ider, int len,
0814                       char *errorDescription)
0815    {
...
1033                case TYPE_ENUMERATED:
1034                  len2 =
1035                    asn1_get_length_der (der + counter, len - counter, &len3);
1036                  if (len2 < 0)
1037                    return ASN1_DER_ERROR;
1038                  if (len2 + len3 > len - counter)
1039                    return ASN1_DER_ERROR;
1040                  _asn1_set_value (p, der + counter, len3 + len2);
1041                  counter += len3 + len2;
1042                  move = RIGHT;
1043                  break;

The above call to asn1_get_length_der was returning an impossibly large value
of 2GB when the Mu analyzer generated corrupt lengths fields for versions,
serial numbers, public key info, and signature structures in X.509 client
certificates, but this could happen in any use of Libtasn1 that is relying
upon asn1_get_length_der, not just SSL, TLS, or GnuTLS.

The asn1_der_decoding function failed to check for cases when
asn1_get_length_der returned a length larger than the enclosing structure's
(void* ider) own length (int len).

When _asn1_set_value was called anyway, it contained a memcpy operation which
assumed the arguments are valid, which tried copy 2GB of memory, leading to a
heap corruption vulnerability.

Simon Josefsson, Libtasn1 maintainer, described the patch as follows: "the
real bug was not in asn1_get_length_der() even if that is the function we
patch[ed]. The callers of that function that did not check that the return
values are sane were buggy. However, instead of fixing all callers, ... we
went for the simpler solution to let the function return an error for a
situation that is unlikely to occur without malicious interaction or data
corruption."

The asn1_der_decoding function shown above is now safe, because
asn1_get_length_der was updated to "[return] -4 when the decoded length value
plus < at >len would exceed < at >der_len," so asn1_der_decoding returns ASN1_DER_ERROR
before it can call _asn1_set_value to trigger the segmentation fault.

Abbreviated GDB Backtrace after the segmentation fault:

(gdb) bt
#0  __memcpy_ia32 () at ../sysdeps/i386/i686/multiarch/../memcpy.S:75
#1  0x00000001 in ?? ()
#2  0x0020eadc in _asn1_set_value (node=0x807ff50, value=0x807ed5c,
    len=2147483652) at parser_aux.c:228
#3  0x0020a646 in asn1_der_decoding (element=0x8078000, ider=0x807ed4e,
    len=687, errorDescription=0x0) at decoding.c:1036
#4  0x001bc7da in gnutls_x509_crt_import (cert=0x8078000, data=0xbfffeae8,
    format=GNUTLS_X509_FMT_DER) at x509.c:226
#5  0x00176d16 in gnutls_pcert_import_x509_raw (pcert=0x807d610,
    cert=0xbfffeae8, format=GNUTLS_X509_FMT_DER, flags=0) at gnutls_pcert.c:201
...
(gdb)

Response / Solution:

TLS record handling vulnerability in GnuTLS [MU-201202-01] is fixed in GnuTLS
3.0.15. For more details, see
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912 .

ASN.1 length decoding vulnerability in Libtasn1 [MU-201202-02] is fixed in
Libtasn1 2.12 and GnuTLS 3.0.16. For more details, see
http://lists.gnu.org/archive/html/help-libtasn1/2012-03/msg00000.html and
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5932 .

History:

Mon, 27 Feb 2012 14:13:45 -0800: TLS Record handling issue reported.
Tue, 28 Feb 2012 10:29:46 +0100: TLS Record handling patch created.
Fri, 02 Mar 2012 18:42:05 +0000: GnuTLS 3.0.15 release announced.
Fri, 02 Mar 2012 14:04:31 -0800: ASN.1 length decoding issue reported.
Wed, 14 Mar 2012 01:04:36 +0100: ASN.1 length decoding patch created.
Mon, 19 Mar 2012 10:57:42 +0100: Libtasn1 2.12 release announced.
Tue, 20 Mar 2012 23:40:00 +0000: Advisory released to the public.

See also:

http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5912
http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/5932
http://lists.gnu.org/archive/html/help-libtasn1/2012-03/msg00000.html
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b495740f2ff66550ca9395b3fda3ea32c3acb185
http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=commitdiff;h=6e534bf4fb3144be51c928ed3efcf9c36055c9c7

Credit:

These vulnerabilities were discovered by Matthew Hall <mhall< at >mudynamics.com>,
Senior Network Protocol Software Engineer at Mu Dynamics, via code inspection
and protocol fuzzing using a Mu 4000 security analyzer.

http://blog.mudynamics.com/wp-content/uploads/2012/03/pgpkey.txt

Mu Dynamics is the leading provider of solutions ensuring the performance and
security of both applications and network infrastructure. The company's
innovative solutions enable customers to confidently meet the challenges posed
by today's rapidly changing networks. This includes the ever-growing number of
applications and devices on the network, and the swift transition to mobile,
virtual and cloud environments. Hundreds of service providers, enterprises,
application developers and network equipment manufacturers count on its
purpose-built solutions, like Mu Studio and Blitz, to ensure their
applications and networks are scalable and secure. Mu Dynamics is
headquartered in Sunnyvale, California.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPaRSqAAoJEEzdDa9po1UUuhkP/RnvCMvQwF+9UyZArKkEDVgu
Z6NvZPcquXZhQ4MNLuIbfkikQnGg+9e7EnbKUzbxxNp7tsVN/ioVGWFHRZw3diSp
Tknw8SZlMghz4Li/nw4ruPQcbT4r6EcDtlkJhTAtI+A2ZAlMkurMUAGIcPhX2CvU
cpNHwGdTPqYcT4+07zzhbhf2M2MD5y1268PNEx9EN9VrZEriyDpFRBKlkkOTeti5
LuSkhIUbiH0wChWGheM54rvsoi4LRSO8QEeeUED1kqBzNI5OJD7AB3g1RJ/K8vEB
DjSkGmKg2siDHifNQUgwOcnED0qcUnN9LAp/1qV0Wn+DJvG3RC5hleJSHYPAW6sk
/fmoOegRN+9TlXVI2ZBzF3ltCaDr8ktbwMUiOU/BZc0MAG2geUvGUyYGkZW0JLZN
MZaJRMzqAS2DrKMapwDWUeNXf5rvQHU49eRweBjyE8lUA2cMtMsvgbFtTOtxAFhl
JYytEI1e7Sh8Xo12GWUxsc6aMjIngFzs2VgfwQc283fnBjZWHZNsdX8gKcKoUY3f
oN6IcQijxfOgCEiWkERsPtcX9GN2+9y2QLs79Z5uDeBJXCOLSzeZg93gWqjEGfcm
64iJwKAWpGcHEr5Po3mxwA+9yREmrth+e6cax9LujiXAn1LrW2SkUXofCafYg8yd
ym77p8ibkKLczxASVN2I
=aqOg
-----END PGP SIGNATURE-----
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Upgrade Unhide package

Rakesh Pandit — 2012-03-12T07:00:10

----- Original Message -----

Currently over burdened with my day job. I will look at updating this packaging on weekend. In case proven packager in list can do it before me reaching on it please go ahead.

Regards,
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Upgrade Unhide package

Eric H. Christensen — 2012-03-10T03:17:09

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Mar 10, 2012 at 03:58:38AM +0100, Yago Jesus wrote:

The package maintainer of unhide is Rakesh Pandit and can be reached at rpandit< at >redhat.com.

- -- Eric

- --------------------------------------------------
Eric H Christensen        eric< at >christensenplace.us
"Sparks"                  sparks< at >fedoraproject.org
    .... . .-.. .-.. ---  .-- --- .-. .-.. -..
097C 82C3 52DF C64A 50C2  E3A3 8076 ABDE 024B B3D1
- --------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBAgAGBQJPWse1AAoJEIB2q94CS7PRZUAQAN6jpfKD4Zgoh7OCDoAvfz+V
xhGZ7JJXdv0J6XR6aEW0h5oCj/Oo7EiabqIypohdeqmYXKE+C3LOG+wJPSfhqXug
TFmulXdiv0YYk9uUzZbVRQQ3AZsoDdselwrNlUw4TOR2JEfko2n103Sxgz+Bx2LV
A2uK5eEyQXHE2vsGtGR3v0wylu7MS0jddCh22SEoCZiBipTJ/6jeENLAtJvbLORo
wwpKZhWDA17J2UAkC/w1EOjJ9MVvuafvf2yRit4zG47MaPRP8JPRyzgImyDnsDS9
HAiHxBYyZOnmdmJANl0T5s+90S0R3GxOME/+AT0tjAOFw8MITf6xXsllkI5TLU3w
w8B+0nRKHFC59JJPKpN4Bpi1qJLSurxyrTyULlPUGTqzO8iWn9d0J8fB0ESwGbOo
cwERCCh0NBIgA0a8Zh5shyeWoJKpRTZe0Fhz2zGlD3Bz8kgktadfYkt9QzegY2dx
c6Ty7ekFoz46Ds62KVhRnFFClMHeDq5QyAMJ9SGsfLLqJkqHoiytXByxYjkluf6T
/ZkaGr2boF47wmSaIqpDtXccDCtGW/4ko1Sps0PRJIwFeUwupX3nRCR8Vi4zUq1c
kJbkDcrUsjCVSehhz5pNHCzPQkUE51gmrsbtKIHQpKqTvgpAWr66Bc0hvV+pTOg0
Kldy2LGv44apGJxaswuU
=t9Te
-----END PGP SIGNATURE-----
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Upgrade Unhide package

Yago Jesus — 2012-03-10T14:40:20

Thanks, Eric, Tristan, Bruno. Im going to open a case in bugzilla

Sorry for the noise in the mail-list :)

2012/3/10 Bruno Wolff III <bruno< at >wolff.to>:
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Upgrade Unhide package

Bruno Wolff III — 2012-03-10T14:35:37

On Sat, Mar 10, 2012 at 03:58:38 +0100,
  Yago Jesus <yjesus< at >security-projects.com> wrote:

Normally the right thing to do is to file an RFE bug against the package.
If the packager isn't active then this might not work too well.
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Upgrade Unhide package

Tristan Santore — 2012-03-10T07:04:58

Hello Yago,

You would have to contact the package maintainer to address the issues
you mentioned. If you are the developer, how about either becoming the
maintainer yourself or becoming a co-maintainer ?
Maybe the current package maintainer has abandoned the packaging process
or has other work commitments, so has been too busy to apply updates.
Please also note, we generally try and keep some kind of version
stability with each release, but that does not mean patches and fixes
are not welcome or desired.

With regards to contacting the right people, you could join
#fedora-devel on irc freenode. Or find the right mailing list.

I hope this helps.

Regards,

Tristan

P.S: You did contact the wrong list, this list is for security issues or
incidences. If there is a security issue with your package please file a
bugzilla on bugzilla.redhat.com.

Upgrade Unhide package

Yago Jesus — 2012-03-10T02:58:38

Hi,

I don't know if this is the correct mail list so if I make a mistake,
please accept my apologizes.

I'm the author of Unhide http://www.unhide-forensics.info and I have
noted that Unhide package from Fedora is outdated. I think you should
upgrade the package because the new releases of Unhide improves the
tool and fixes some bugs.

Thanks
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Self introduction

Tristan Santore — 2012-03-03T00:26:48

Christoper,

This list is mainly a security response list, not a public forum for
security issue. I am not quite sure what other advice I can give you, if
you are interested in security related issues.

Regards,

Tristan

Self introduction

Christopher Meng — 2012-03-03T00:13:31

Hi everyone,I just join this list in order to help improving the security team.

Re: security Digest, Vol 51, Issue 1

Tristan Santore — 2011-12-20T15:55:44

Hello,
Anything is possible, although it might result in some undesired
results. Why not just use a live disc ?

Also, this list is for security reports, not end-user support. Please
either add the fedora mailing list, and ask your question there, or join
#fedora on the irc network freenode.

https://lists.fedoraproject.org/mailman/listinfo

Look for users list.

I hope that helps.

Regards,
Tristan

thank you very much for the excellent Fedora

2011-12-19T13:31:44

Good morning,
thank you very much for the excellent Fedora.
I worry about safety, surf the Internet without antivitus.
Is it possible to configure the system or boot partition for the linux
read-only?
Thus, placing the system in a partition of the data reading and a read /
write the system is not corrupt.

Greetings and thank you very much.

Roberto


--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Re: Review Request: python-pyflag - Forensic and Log Analysis GUI

soumya chakraborty — 2011-11-25T15:11:46

devel list then

Regards,

Soumya

Re: security Digest, Vol 50, Issue 1

Tristan Santore — 2011-11-25T12:06:51

Soumya,

you are barking at the wrong tree here. You should find a trusted
packager, that is willing to review the package request. You would be
better off requesting that on the devel list.

https://admin.fedoraproject.org/mailman/listinfo/devel

Regards,

Tristan

Review Request: python-pyflag - Forensic and Log Analysis GUI

soumya chakraborty — 2011-11-24T21:07:33

Hi

Please review the package request for
Pyflag<http://www.pyflag.net/cgi-bin/moin.cgi>.
This is in the packaging wishlist for Fedora Security Spin. The only
problem I found with packaging this tool was a no show from upstream. After
sending mails and pinging them in #irc didn't help to get a single
response. The package which is build has a "Incorrect fsf address" error
which cannot be removed by me and can be only be sorted out by the upstream.

Please review the package and let me know the suggestions The Bugzilla link
is here <https://bugzilla.redhat.com/show_bug.cgi?id=756856> .

Thanks,
---------------------------------------
Soumya Kanti Chakraborty
--
security mailing list
security< at >lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/security

Ruxcon 2011 Final Call For Papers

2011-08-15T10:53:07

Ruxcon 2011 Final Call For Papers

The Ruxcon team is pleased to announce the final call for papers for the seventh annual Ruxcon conference.

This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of October.

* What is Ruxcon?

Ruxcon is the premier technical computer security conference in the Australia-Pacific region. The conference aims to bring together the individual talents of the best and brightest security folk in the region, through live presentations, activities and demonstrations.

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information, please visit http://www.ruxcon.org.au

* Presentation Information

Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech.

* Presentation Submissions

Ruxcon would like to invite people who are interested in security to submit a presentation.

Topics of interest include, but are not limited to:

Submissions should thoroughly outline your desired presentation subject.

If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations () ruxcon org au

The deadline for submissions is the 15th of October.

If approved we will additionally require:

i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).

* Contact Details

Presentation Submissions: presentations () ruxcon org au

Ruxcon 2011 Final Call For Papers

2011-08-15T10:53:07

Ruxcon 2011 Final Call For Papers

The Ruxcon team is pleased to announce the final call for papers for the seventh annual Ruxcon conference.

This year the conference will take place over the weekend of 19th and 20th of November at the CQ Function Centre, Melbourne, Australia.

The deadline for submissions is the 15th of October.

* What is Ruxcon?

The conference is held over two days in a relaxed atmosphere, allowing attendees to enjoy themselves whilst networking within the community and expanding their knowledge of security.

Live presentations and activities will cover a full range of defensive and offensive security topics, varying from previously unpublished research to required reading for the security community.

For more information, please visit http://www.ruxcon.org.au

* Presentation Information

Presentations are set to run for 50 minutes, and will be of a formal nature, with slides and a speech.

* Presentation Submissions

Ruxcon would like to invite people who are interested in security to submit a presentation.

Topics of interest include, but are not limited to:

Submissions should thoroughly outline your desired presentation subject.

If you have any enquiries about submissions, or would like to make a submission, please send an e-mail to presentations () ruxcon org au

The deadline for submissions is the 15th of October.

If approved we will additionally require:

i. A brief personal biography (between 2-5 paragraphs in length).
ii. A description on your presentation (between 2-5 paragraphs in length).

* Contact Details

Presentation Submissions: presentations () ruxcon org au

Re: Fedora Security URL full Path!

Matt McCutchen — 2011-08-04T01:18:15

This is not a security question, even if you are using the answer for
some kind of security update tracking.

To answer your question, look at the yum repo files in the
fedora-release package (on a Fedora system or download the desired
version manually from
http://koji.fedoraproject.org/koji/packageinfo?packageID=9) and append
repodata/primary.xml.gz to the basedir entries.

Fedora Security URL full Path!

Jan Muhammad — 2011-08-03T17:25:15

Hi Group,

In configuring my Patch Management System-- Pakiti (http://pakiti.sourceforge.net/), I need to specify the URL for Fedora based OS. 

What would be the URL to put the full path to the file which contains the list of packages
provided by the repository?
For example the Scientific Linux has URL to full path:
http://linuxsoft.cern.ch/cern/slc54/x86_64/yum/os/repodata/primary.xml.gz


Also the Debian based systems working with following details:

Repository Name: Debian 5.x main
Select architecture: x86_64
URL:
http://security.ubuntu.com/ubuntu/dists/karmic-security/main/binary-amd64/Packages.gz
Tick contains security updates
Select OS group: Debian 5.x

Thanks in advance for help!

Regards

-Jan

one numpty later

Tim Thomas — 2011-06-20T20:37:23

Hi again, I realised just after I sent the last mail and went in to disable
the wife's acct, her acct was set 'yes' to auto log on. Is this causing the
problem when I am logged in? (mine set to no) I have disabled her auto log
on for now.

T