[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160525022346.7244DABC185@smtpvmsrv1.mitre.org>
Date: Tue, 24 May 2016 22:23:46 -0400 (EDT)
From: cve-assign@...re.org
To: liuyue0310@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, davea42@...uxmail.org
Subject: Re: CVE request: Multiple vunerabilities in libdwarf & dwarfdump
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> And anther one https://bugzilla.redhat.com/show_bug.cgi?id=1330237
> There is a NULL pointer dereference bug in libdwarf-20160115 and latest git code.
>
> The bug is at file dwarf_leb.c:147
> 143 byte_length++;
> 144 if (byte_length > BYTESLEBMAX) {
> 145 /* Erroneous input. What to do?
> 146 Abort? Return error? Just stop here?*/
> 147 *leb128_length = BYTESLEBMAX; <- $pc
> 148 return number;
> 149 }
> 150 }
>
> which triggered by dwarf_form.c:918
> 913 *return_sval = (Dwarf_Signed) ret_value;
> 914 return DW_DLV_OK;
> 915 }
> 916
> 917 case DW_FORM_sdata:
> 918 ret_value =
> 919 (_dwarf_decode_s_leb128(attr->ar_debug_ptr, NULL));
> 920 *return_sval = ret_value;
> 921 return DW_DLV_OK;
> 922
Use CVE-2016-5027.
> DW201605-019
>
> id: DW201605-019
>
> cve:
>
> datereported: 20160523
>
> reportedby: Yue Liu
>
> vulnerability: Null dereference in print_frame_inst_bytes (dwarfdump)
>
> product: libdwarf
>
> description: The null dereference is due to a corrupted object file.
> Libdwarf was not dealing with empty (bss-like) sections since it really
> did not expect to see such in sections it reads! Now libdwarf catches the
> object error so dwarfdump sees the section as empty (as indeed it is!).
>
> datefixed: 20160523
>
> references: dwarftests/liu/NULLdeference0522c.elf
>
> gitfixid: a55b958926cc67f89a512ed30bb5a22b0adb10f4
>
> tarrelease:
Use CVE-2016-5028.
> DW201605-018
>
> id: DW201605-018
>
> cve:
>
> datereported: 20160522
>
> reportedby: Yue Liu
>
> vulnerability: Null dereference in create_fullest_file_path().
>
> product: libdwarf
>
> description: The null dereference in create_fullest_file_path() causes a
> crash. This is due to corrupted dwarf and the fix detects this corruption
> and if that null string pointer happens undetected a static string is
> substituted so readers can notice the situation.
>
> 202 }
> 203 if (dirno > 0 && fe->fi_dir_index > 0) {
> 204 inc_dir_name = (char *)
> line_context->lc_include_directories[
> 205 fe->fi_dir_index - 1];
> 206 incdirnamelen = strlen(inc_dir_name); <- $pc
> 207 }
> 208 full_name = (char *) _dwarf_get_alloc(dbg,
> #0 create_fullest_file_path (dbg=<optimized out>,
> fe=0x68d510, line_context=0x68c4f0, name_ptr_out=<optimized
> out>, error=0x7fffffffe2b8) at ./dwarf_line.c:206
> #1 0x00007ffff7b6d3f9 in dwarf_filename (context=<optimized
> out>, fileno_in=<optimized out>, ret_filename=0x7fffffffe280,
> error=0x7fffffffe2b8) at ./dwarf_line.c:1418
> #2 dwarf_linesrc (line=<optimized out>,
> ret_linesrc=<optimized out>, error=<optimized out>) at
> ./dwarf_line.c:1436
>
>
> datefixed: 20160522
>
> references: dwarftests/liu/NULLdereference0522.elf
>
> gitfixid: acae971371daa23a19358bc62204007d258fbc5e
>
> tarrelease:
Use CVE-2016-5029.
> DW201605-017
>
> id: DW201605-017
>
> cve:
>
> datereported: 20160519
>
> reportedby: Yue Liu
>
> vulnerability: Null dereference bug in
> _dwarf_calculate_info_section_end_ptr().
>
> product: libdwarfj
>
> description: NULL dereference bug in
> _dwarf_calculate_info_section_end_ptr().
>
> 1742 Dwarf_Off off2 = 0;
> 1743 Dwarf_Small *dataptr = 0;
> 1744
> 1745 dbg = context->cc_dbg;
> 1746 dataptr = context->cc_is_info? dbg->de_debug_info.dss_data: <- $pc
> 1747 dbg->de_debug_types.dss_data;
> 1748 off2 = context->cc_debug_offset;
> 1749 info_start = dataptr + off2;
> 1750 info_end = info_start + context->cc_length +
> #0 _dwarf_calculate_info_section_end_ptr
> (context=context@...ry=0x0) at dwarf_query.c:1746
> #1 0x00002aaaaace307d in
> _dwarf_extract_string_offset_via_str_offsets
> (dbg=dbg@...ry=0x655a70, info_data_ptr=0x6629f0
> "", attrnum=attrnum@...ry=121,
> attrform=attrform@...ry=26, cu_context=0x0,
> str_sect_offset_out=str_sect_offset_out@...ry=0x7fffffffd718,
> error=error@...ry=0x7fffffffd878) at dwarf_form.c:1099
> #2 0x00002aaaaacf4ed7 in dwarf_get_macro_defundef
> (macro_context=macro_context@...ry=0x65b790,
> op_number=op_number@...ry=1,
> line_number=line_number@...ry=0x7fffffffd858,
> index=index@...ry=0x7fffffffd860,
> offset=offset@...ry=0x7fffffffd868,
> forms_count=forms_count@...ry=0x7fffffffd7ce,
> macro_string=macro_string@...ry=0x7fffffffd870,
> error=error@...ry=0x7fffffffd878) at dwarf_macro5.c:557
> ------
> _dwarf_calculate_info_section_end_ptr (context=context@...ry=0x0) at
> dwarf_query.c:1746
> 1746 dataptr = context->cc_is_info? dbg->de_debug_info.dss_data:
> gef> p/x $rdi
> $4 = 0x0
>
>
> datefixed: 20160522
>
> references: regressiontests/liu/NULLdereference0519.elf
>
> gitfixid: 6fa3f710ee6f21bba7966b963033a91d77c952bd
>
> tarrelease:
Use CVE-2016-5030.
However, is this a typo or is there a "libdwarfj" library?
> DW201605-016
>
> id: DW201605-016
>
> cve:
>
> datereported: 20160519
>
> reportedby: Yue Liu
>
> vulnerability: Invalid dwarf leads to dwarfdump crash in
> print_frame_inst_bytes.
>
> product: dwarfdump
>
> description: Corrupted dwarf crashes dwarfdump
>
> 1297 }
> 1298 len = len_in;
> 1299 endpoint = instp + len;
> 1300 for (; len > 0;) {
> 1301 unsigned char ibyte = *instp; <- $pc
> 1302 int top = ibyte & 0xc0;
> 1303 int bottom = ibyte & 0x3f;
> 1304 int delta = 0;
> 1305 int reg = 0;
> #0 print_frame_inst_bytes (dbg=dbg@...ry=0x655ca0,
> cie_init_inst=<optimized out>, len_in=<optimized out>,
> data_alignment_factor=-4, code_alignment_factor=4,
> addr_size=addr_size@...ry=4, offset_size=4, version=3,
> config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
> at print_frames.c:1301
> #1 0x000000000041b70c in print_one_cie
> (dbg=dbg@...ry=0x655ca0, cie=<optimized out>,
> cie_index=cie_index@...ry=2, address_size=<optimized out>,
> config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
> at print_frames.c:1161
> #2 0x000000000041cf52 in print_frames (dbg=0x655ca0,
> print_debug_frame=print_debug_frame@...ry=1, print_eh_frame=0,
> config_data=config_data@...ry=0x63cda0 <g_config_file_data>)
> at print_frames.c:2229
> gef> p/x $r13
> $1 = 0x4bcad8
> gef> p/x *$r13
> Cannot access memory at address 0x4bcad8
>
>
> datefixed: 20160522
>
> references: regressiontests/liu/OOB_READ0519.elf
>
> gitfixid: 6fa3f710ee6f21bba7966b963033a91d77c952bd
>
> tarrelease:
If the vulnerability is specific to dwarfdump, and is not present in
libdwarf itself, then we need additional analysis from you before
assigning a CVE ID. "crashes dwarfdump" is not sufficient because we
think that dwarfdump has no need to remain running after a bad file is
encountered. There cannot be a CVE ID if a simple and complete
workaround for the crash problem is to not try to dump that file
again. If you believe the crash is potentially exploitable for code
execution, please provide further information about that.
> DW201605-015
>
> id: DW201605-015
>
> cve:
>
> datereported: 20160517
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in print_frame_inst_bytes()
>
> product: libdwarf
>
> description: Test object shows an invalid read in
> print_frame_inst_bytes().
>
> 1294 for (; len > 0;) {
> 1295 unsigned char ibyte = *instp; <- $pc
> 1296 int top = ibyte & 0xc0;
> #0 print_frame_inst_bytes (dbg=dbg@...ry=0x654c80,
> cie_init_inst=<optimized out>, len=503715, data_alignment_factor=-4,
> code_alignment_factor=1, addr_size=addr_size@...ry=4, offset_size=4,
> version=3, config_data=config_data@...ry=0x63bda0
> <g_config_file_data>) at print_frames.c:1295
> #1 0x000000000041b64c in print_one_cie (dbg=dbg@...ry=0x654c80,
> cie=<optimized out>, cie_index=cie_index@...ry=1,
> address_size=<optimized out>, config_data=
> config_data@...ry=0x63bda0 <g_config_file_data>) at print_frames.c:1161
> #2 0x000000000041ce92 in print_frames (dbg=0x654c80,
> print_debug_frame=print_debug_frame@...ry=1, print_eh_frame=0,
> config_data=config_data@...ry=0x63bda0 <g_config_file_data>)
> at print_frames.c:2209
> gef> x/10x $r13
> 0x5e7981: Cannot access memory at address 0x5e7981
> gef> p/x $r13
> $14 = 0x5e7981
>
>
> datefixed: 20150518
>
> references: regressiontests/liu/OOB0517_03.elf
>
> gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54
>
> tarrelease:
Use CVE-2016-5031.
> DW201605-014
>
> id: DW201605-014
>
> cve:
>
> datereported: 20160517
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in dwarf_get_xu_hash_entry()
>
> product: libdwarf
>
> description: Test object shows an invalid read in dwarf_get
> _xu_hash_entry, lin 211.
>
> #0 dwarf_get_xu_hash_entry (xuhdr=xuhdr@...ry=0x657360,
> index=index@...ry=2897626028, hash_value=
> hash_value@...ry=0x7fffffffd5b0,
> index_to_sections=index_to_sections@...ry=0x7fffffffd5a8,
> err=err@...ry=0x7fffffffdb08) at dwarf_xu_index.c:211
> #1 0x00002aaaaacfd05e in _dwarf_search_fission_for_key (
> dbg=0x654a50, error=0x7fffffffdb08, percu_index_out=<synthetic pointer>,
> key_in=0x7fffffffd670, xuhdr=0x657360) at dwarf_xu_index.c:363
> #2 dwarf_get_debugfission_for_key (dbg=dbg@...ry=0x654a50,
> key=key@...ry=0x7fffffffd670, key_type=key_type@...ry=0x2aaaaad15e2a
> "tu", percu_out=percu_out@...ry=0x65a830,
> error=error@...ry=0x7fffffffdb08) at dwarf_xu_index.c:577
>
>
> datefixed: 20150518
>
> references: regressiontests/liu/OOB0517_02.elf
>
> gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54
>
> tarrelease:
Use CVE-2016-5032.
> DW201605-013
>
> id: DW201605-013
>
> cve:
>
> datereported: 20160517
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in print_exprloc_content
>
> product: libdwarf
>
> description: Test object shows an invalid write in print_exprloc_content.
>
> #0 print_exprloc_content (dbg=dbg@...ry=0x654ea0,
> die=die@...ry=0x65b110, attrib=attrib@...ry=0x65b590,
> esbp=esbp@...ry=0x7fffffffcef0, showhextoo=1) at print_die.c:4182
> #1 0x0000000000412fb1 in get_attr_value (dbg=dbg@...ry=0x654ea0,
> tag=<optimized out>, die=die@...ry=0x65b110,
> dieprint_cu_goffset=dieprint_cu_goffset@...ry=11,
> attrib=attrib@...ry=0x65b590, srcfiles=srcfiles@...ry=0x0,
> cnt=cnt@...ry=0, esbp=esbp@...ry=0x7fffffffcef0, show_form=0,
> local_verbose=0) at print_die.c:4972
>
>
> datefixed: 20150518
>
> references: regressiontests/liu/OOB0517_01.elf
>
> gitfixid: ac6673e32f3443a5d36c2217cb814000930b2c54
>
> tarrelease:
Use CVE-2016-5033.
> DW201605-012
>
> id: DW201605-012
>
> cve:
>
> datereported: 20160513
>
> reportedby: Yue Liu
>
> vulnerability: OOB write. From relocation records
>
> product: libdwarf
>
> description: Test object shows an invalid write in dwarf_elf_access.c
> (when doing the relocations). Adding the relocation value to anything
> overflowed and disguised the bad relocation record. With a 32bit kernel
> build the test could show a double-free and coredump due to the unchecked
> invalid writes from relocations.
>
> datefixed: 20160517
>
> references: regressiontests/liu/HeapOverflow0513.elf
>
> gitfixid: 10ca310f64368dc083efacac87732c02ef560a92
>
> tarrelease:
Use CVE-2016-5034.
> DW201605-011
>
> id: DW201605-011
>
> cve:
>
> datereported: 20160506
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in _dwarf_read_line_table_header
>
> product: libdwarf
>
> description: Test object shows null dereference at line 62 of
> dwarf_line_table_reader.c. Frame code and linetable code was not noticing
> data corruption.
>
> datefixed: 20160512
>
> references: regressiontests/liu/OOB_read4.elf
>
> gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b
>
> tarrelease:
Use CVE-2016-5035.
> DW201605-010
>
> id: DW201605-010
>
> cve:
>
> datereported: 20160506
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in dump_block
>
> product: libdwarf
>
> description: Test object shows null dereverence at line 186 of
> dump_block() in print_sections.c Frame code was not noticing frame data
> corruption.
>
> datefixed: 20160512
>
> references: regressiontests/liu/OOB_read3.elf
> regressiontests/liu/OOB_read3_02.elf
>
> gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b
>
> tarrelease:
Use CVE-2016-5036.
> DW201605-009
>
> id: DW201605-009
>
> cve:
>
> datereported: 20160505
>
> reportedby: Yue Liu
>
> vulnerability: NULL dereference in _dwarf_load_section
>
> product: libdwarf
>
> description: Test object shows null dereverence at line 1010
> if(!strncmp("ZLIB",(const char *)src,4)) { in dwarf_init_finish.c The zlib
> code was not checking for a corrupted length-value.
>
> datefixed: 20160506
>
> references: regressiontests/liu/NULLderefer0505_01.elf
>
> gitfixid: b6ec2dfd850929821626ea63fb0a752076a3c08a
>
> tarrelease: 20160507
Use CVE-2016-5037.
> DW201605-008
>
> id: DW201605-008
>
> cve:
>
> datereported: 20160505
>
> reportedby: Yue Liu
>
> vulnerability: OOB read in dwarf_get_macro_startend_file()
>
> product: libdwarf
>
> description: Test object shows out of bound read. OOB at: line 772
> *src_file_name = macro_context->mc_srcfiles[trueindex]; in dwarf_macro5.c
> A string offset into .debug_str is outside the bounds of the .debug_str
> section.
>
> datefixed: 20160512
>
> references: regressiontests/liu/OOB0505_02.elf
> regressiontests/liu/OOB0505_02_02.elf
>
> gitfixid: 82d8e007851805af0dcaaff41f49a2d48473334b
>
> tarrelease:
Use CVE-2016-5038.
> DW201605-007
>
> id: DW201605-007
>
> cve:
>
> datereported: 20160505
>
> reportedby: Yue Liu
>
> vulnerability: OOB read bug in get_attr_value()
>
> product: libdwarf
>
> description: Test object shows out of bound read. Object had data
> all-bits-on so the existing length check did not work due to wraparound.
> Added a check not susceptible to that error
> (DW_DLE_FORM_BLOCK_LENGTH_ERROR).
>
> datefixed: 20160506
>
> references: regressiontests/liu/OOB0505_01.elf
>
> gitfixid: eb1472afac95031d0c9dd8c11d527b865fe7deb8
>
> tarrelease: 20160507
Use CVE-2016-5039.
> DW201605-006
>
> id: DW201605-006
>
> cve:
>
> datereported: 20160505
>
> reportedby: Yue Liu
>
> vulnerability: Two Heap-Overflow bug
>
> product: libdwarf
>
> description: Two test objects showing a heap overflow in libdwarf when
> using dwarfdump. It seems that these were fixed by the previous git
> update. Neither gdb nor valgrind find any errors when building with
> yesterday's commit.
>
> datefixed: 20160504
>
> references: regressiontests/liu/free_invalid_address.elf
> regressiontests/liu/heapoverflow01b.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
We cannot assign a CVE ID without more analysis from you about why
these two issues are being combined into a single DW201605-006 ID, and
about whether they are independent of the issue "fixed by the previous
git update." A "heap overflow" is often a consequence of other code
problems, and the term "heap overflow" is often misused to refer to an
invalid read operation instead of an invalid write operation.
> DW201605-005
>
> id: DW201605-005
>
> cve:
>
> datereported: 20160502
>
> reportedby: Yue Liu
>
> vulnerability: A specially crafted DWARF section results in reading a
> compilation unit header that crashes the application.
>
> product: libdwarf
>
> description: If the data read for a compilation unit header contains a too
> large length value the library will read outside of its bounds and crash
> the application.
>
> datefixed: 20160504
>
> references: regressiontests/liu/null02.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
Use CVE-2016-5040.
> DW201605-004
>
> id: DW201605-004
>
> cve:
>
> datereported: 20160502
>
> reportedby: Yue Liu
>
> vulnerability: A specially crafted DWARF section results in a null
> dereference reading debugging information entries which crashes the
> application.
>
> product: libdwarf
>
> description: If no DW_AT_name is present in a debugging information entry
> using DWARF5 macros a null dereference in dwarf_macro5.c will crash the
> application.
>
> datefixed: 20160504
>
> references: regressiontests/liu/null01.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
Use CVE-2016-5041.
> DW201605-003
>
> id: DW201605-003
>
> cve:
>
> datereported: 20160502
>
> reportedby: Yue Liu
>
> vulnerability: A specially crafted DWARF section results in an infinite
> loop that eventually crashes the application.
>
> product: libdwarf
>
> description: In dwarf_get_aranges_list() an invalid count will iterate,
> reading from memory addresses that increase till it all fails.
>
> datefixed: 20160504
>
> references: regressiontests/liu/infiniteloop.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
Use CVE-2016-5042.
> DW201605-002
>
> id: DW201605-002
>
> cve:
>
> datereported: 20160502
>
> reportedby: Yue Liu
>
> vulnerability: A specially crafted DWARF section results in a read outside
> the bounds of in memory data so the calling application can crash.
>
> product: libdwarf
>
> description: Out of bound read bug in libdwarf git code. dwarf_dealloc()
> did not check the Dwarf_Ptr space argument before using it. This will lead
> to a out-of-bound read bug.
>
> backtrace:
> #0 dwarf_dealloc (dbg=dbg@...ry=0x655f30, space=0xa0,
> alloc_type=alloc_type@...ry=1) at dwarf_alloc.c:477
> #1 0x00002aaaaacf3296 in dealloc_srcfiles
> (dbg=0x655f30, srcfiles=0x66b8f0, srcfiles_count=17) at
> dwarf_macro5.c:1025 #2 0x00002aaaaacf50e6 in dealloc_srcfiles
> (srcfiles_count=<optimized out>, srcfiles=<optimized out>,
> dbg=<optimized out>) at dwarf_macro5.c:1021 -----
> gef> p &r->rd_dbg
> $14 = (void **) 0x90
>
>
> datefixed: 20160504
>
> references: regressiontests/liu/outofbound01.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
Use CVE-2016-5043.
> DW201605-001
>
> id: DW201605-001
>
> cve:
>
> datereported: 20160502
>
> reportedby: Yue Liu
>
> vulnerability: A specially crafted DWARF section results in a duplicate
> free() in libdwarf and the calling application will crash.
>
> product: libdwarf
>
> description: In file dwarf_elf_access.c:1071
>
> WRITE_UNALIGNED(dbg,target_section + offset,
> &outval,sizeof(outval),reloc_size);
>
>
> A crafted ELF file may lead to a large offset value, which bigger than the
> size of target_section heap chunk, then this WRITE_UNALIGNED() function
> will write the value of &outval out of the heap chunk. offset is a 64bit
> unsigned int value, so this is more than a heap overflow bug, but also a
> Out-of-Bound write bug. So WRITE_UNALIGNED() need more strictly checking
> to prevent this.
>
> datefixed: 20160504
>
> references: regressiontests/liu/heapoverflow01.elf
>
> gitfixid: 98a3da1e8237fe0d45b67ef77f3fa5ed9ff0215f
>
> tarrelease: 20160507
Use CVE-2016-5044.
- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJXRQuYAAoJEHb/MwWLVhi228oP+gJ1Dvqw1e+qh+daCWr2MQt4
6TTVHAcdclKRByocqSDIzac0/qIzePuHlhke4h842y6p92Ldr4zjfQZAcA18KeNt
SSrD+v6QYeEsjWF0rgsOxLfjpNuHa6D3sjxXA8jeDN8OkQvnqCHX1gnW0pPLadF8
Xt0xZBTEdTvKinNix5mYrtkofLcNBBepKSu5VkfEXFLzP+rZKZVxvUD+1pNKWUOL
fHYk97aL8SH1HeLcXATs8S6Pe2W3VMxsW5AleqTEGeIm9jRB9JR/UgldFP9DkjX2
GPnefpDDk/enizVw0yQxUGX2VpoXhJN/cAQ9vagegyXLGhoqWxiNTYyPq6RgNQu0
WpPdJyy+6TXDx3dLeDoTy4O30l7A1WKW8dl4WGwSXlfILVn/mSjfPjHyfmE/otfN
r0Ek/palVxlWwQRTZ924uqkQn7Pz+ACA8fl8RapQwxGgveyEXuGcw33jhLv+NUZx
H12FdhsspZa568k8mEKZJiST44cfyBZwj+aNZOoV/MC180qTpdfgZlsH5+CZa59O
P9XSImd/MWaUsLV34cCCY3qDPdP4uWAO9PKbic82JNXJbXhsxavm4U90qPDXYTCe
58KJHA+Amq0j0SAzLLhNk5Q/Tps0fjbZ2RvyXQuQ8vDzxq6IXT9V0w5pr8jg3RRr
d2iFHpD4XlMwxmlXD0Er
=/Qjv
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
